Fix crash #6

X-Ryl669 · 2019-12-21T22:28:59Z

Fix a crash in card manager when being run for hours. At some point in time, the lv_label's ext_attr's text is NULL and since no test are done on this value, it's crashing when it's dereferencing. The only way in the code this text can be NULL is if it's created and never assigned with lv_label_set_text (possible in the current code?).

Fix #2

At some point in time, the lv_label's ext_attr's text is NULL and since no test are done on this value, it's crashing when it's dereferencing. The only way in the code this text can be NULL is if it's created and never assigned with lv_label_set_text (possible in the current code).

ouellettetech

You should have this in a branch based off master that way it can be merged in independently.
Also curious, (haven't had time to read through all of the code) what A the side effects or not calling the draw label, and how we got into this state, is there something that should be done earlier in the code?

X-Ryl669 · 2019-12-27T11:15:16Z

Honestly, the build system is a real PITA. Don't know why you've made it so complex. As a result, debugging is very hard and you have a lot of memory corruption happening everywhere.
Some are easy to spot, like this one (usage while not initialized). Some are almost impossible to debug (like this one:

SIGSEGV
#0  __ftello (f=0x2f2f3a4f) at src/stdio/ftell.c:19
19              FLOCK(f);
(gdb) p f
$32 = (FILE *) 0x2f2f3a4f  => not a pointer, ASCII for "O:/u"
(gdb) p *f
Cannot access memory at address 0x2f2f3a4f
(gdb) bt
#0  __ftello (f=0x2f2f3a4f) at src/stdio/ftell.c:19
#1  0x77fc2920 in ftell (f=<optimized out>) at src/stdio/ftell.c:27
#2  0x004319df in pcfs_tell (file_p=<optimized out>, pos_p=0x7ffffac8) at oboo_gui/lv_omega_fs.c:109
#3  0x00424805 in lv_fs_tell (file_p=file_p@entry=0x7ffffaf4, pos=pos@entry=0x7ffffaf0) at lvgl/lv_misc/lv_fs.c:242
#4  0x0042f7f5 in lv_draw_img (coords=coords@entry=0x7ffffb30, mask=mask@entry=0x7ffffb70, style=style@entry=0x5422b0 <newStyle.4333>, src=<optimized out>) at lvgl/lv_draw/lv_draw.c:466
#5  0x0042d19f in lv_img_design (img=0x4ef240 <work_mem+3580>, mask=<optimized out>, mode=<optimized out>) at lvgl/lv_objx/lv_img.c:307
#6  0x004277db in lv_refr_obj (obj=0x4ef240 <work_mem+3580>, mask_ori_p=0x7ffffbd8) at lvgl/lv_core/lv_refr.c:465
#7  0x00427837 in lv_refr_obj (obj=0x4ef0a4 <work_mem+3168>, mask_ori_p=<optimized out>) at lvgl/lv_core/lv_refr.c:491
#8  0x00427837 in lv_refr_obj (obj=0x4ef034 <work_mem+3056>, mask_ori_p=<optimized out>) at lvgl/lv_core/lv_refr.c:491
#9  0x00427873 in lv_refr_obj_and_children (top_p=0x4ef034 <work_mem+3056>, mask_p=mask_p@entry=0x7ffffc98) at lvgl/lv_core/lv_refr.c:400
#10 0x004278f1 in lv_refr_area_part_vdb (area_p=area_p@entry=0x4f64ba <inv_buf+10>) at lvgl/lv_core/lv_refr.c:339
#11 0x00427a47 in lv_refr_area_with_vdb (area_p=0x4f64ba <inv_buf+10>) at lvgl/lv_core/lv_refr.c:303
#12 lv_refr_areas () at lvgl/lv_core/lv_refr.c:250
#13 lv_refr_task (param=<optimized out>) at lvgl/lv_core/lv_refr.c:177
#14 0x00426031 in lv_task_exec (lv_task_p=0x4ee4b4 <work_mem+112>) at lvgl/lv_misc/lv_task.c:284
#15 0x004260ab in lv_task_handler () at lvgl/lv_misc/lv_task.c:106
#16 0x00432aef in oboo_graphics_handle () at oboo_gui/oboo.c:48
#17 0x00401a1f in main (argc=<optimized out>, argv=<optimized out>) at main.c:117
(gdb) up
#1  0x77fc2920 in ftell (f=<optimized out>) at src/stdio/ftell.c:27
27              off_t pos = __ftello(f);
(gdb) up
#2  0x004319df in pcfs_tell (file_p=<optimized out>, pos_p=0x7ffffac8) at oboo_gui/lv_omega_fs.c:109
109         *pos_p = ftell(*fp);
(gdb) up
#3  0x00424805 in lv_fs_tell (file_p=file_p@entry=0x7ffffaf4, pos=pos@entry=0x7ffffaf0) at lvgl/lv_misc/lv_fs.c:242
242         lv_fs_res_t res = file_p->drv->tell(file_p->file_d, pos);
(gdb) p file_p
$34 = (lv_fs_file_t *) 0x7ffffaf4
(gdb) p *file_p
$35 = {file_d = 0x4ef284 <work_mem+3648>, drv = 0x4ef240 <work_mem+3580>}
(gdb) p *file_p->drv
$36 = {letter = -92 '\244', file_size = 78, rddir_size = 56, ready = 0x0, open = 0x0, close = 0x1d000a, remove = 0x80006d, read = 0x42d501 <lv_img_signal>,
  write = 0x42d101 <lv_img_design>, seek = 0x4ef284 <work_mem+3648>, tell = 0x0, trunc = 0x5582c0, size = 0x0, free = 0xc1, dir_open = 0x2, dir_read = 0x4ef2b8 <work_mem+3700>,
  dir_close = 0x4ef1d0 <work_mem+3468>}
(gdb) up
#4  0x0042f7f5 in lv_draw_img (coords=coords@entry=0x7ffffb30, mask=mask@entry=0x7ffffb70, style=style@entry=0x5422b0 <newStyle.4333>, src=<optimized out>) at lvgl/lv_draw/lv_draw.c:466
466                     lv_fs_tell(&file, &act_pos);
(gdb) p file
$37 = {file_d = 0x4ef1ac <work_mem+3432>, drv = 0x4ee5d4 <work_mem+400>}
(gdb) p *file->drv
$38 = {letter = 79 'O', file_size = 4, rddir_size = 0, ready = 0x0, open = 0x4318f1 <pcfs_open>, close = 0x43199d <pcfs_close>, remove = 0x0, read = 0x4319ad <pcfs_read>, write = 0x0,
  seek = 0x4319c5 <pcfs_seek>, tell = 0x4319d5 <pcfs_tell>, trunc = 0x0, size = 0x0, free = 0x0, dir_open = 0x0, dir_read = 0x0, dir_close = 0x0}
(gdb) list
461                     res = lv_fs_read(&file, buf, useful_data, &br);
462
463                     map_fp(&line, &mask_com, (uint8_t *)buf, style->image.opa, img_data.header.chroma_keyed, img_data.header.alpha_byte,
464                             style->image.color, style->image.intense);
465
466                     lv_fs_tell(&file, &act_pos);
467                     lv_fs_seek(&file, act_pos + next_row);
468                     line.y1++;    /*Go down a line*/
469                     line.y2++;
470                 }
(gdb) p file
$39 = {file_d = 0x4ef1ac <work_mem+3432>, drv = 0x4ee5d4 <work_mem+400>}
(gdb) p &file
$40 = (lv_fs_file_t *) 0x7ffffacc
(gdb) p act_pos
$41 = 27004
(gdb) down
#3  0x00424805 in lv_fs_tell (file_p=file_p@entry=0x7ffffaf4, pos=pos@entry=0x7ffffaf0) at lvgl/lv_misc/lv_fs.c:242
242         lv_fs_res_t res = file_p->drv->tell(file_p->file_d, pos);
(gdb) p file_p
$42 = (lv_fs_file_t *) 0x7ffffaf4

There, the pointer to file_p->file_d changes when going down in a lower frame so it's likely a stack corruption going on. This is almost impossible to debug since it can happen from any other place (and the program is multithreaded).

In the end it would be so much easier if the card manager could be compiled on a computer so we could run with valgrind in order to spot all of those pesky bugs (valgrind on the target does not work, it's failing immediately with out-of-memory errors or allocation errors depending on the run options).

X-Ryl669 · 2019-12-27T11:17:46Z

BTW, the other commits are from the other PRs, so if you merge them, this one will collapse to a single commit.

ouellettetech · 2019-12-27T20:18:06Z

I know the other commits are from a different pull request. The problem is that if one of them is rejected it holds up other pull requests. That's why you should do them as separate requests.

greenbreakfast · 2020-01-03T19:05:18Z

I know the other commits are from a different pull request. The problem is that if one of them is rejected it holds up other pull requests. That's why you should do them as separate requests.

100% agree.

Please isolate the card manager change

greenbreakfast · 2020-02-21T21:48:55Z

Manually rolled in the card manager fix in 86b7294
Closing this PR.

X-Ryl669 added 3 commits December 21, 2019 23:14

Fix warnings

a26f356

Add support for configurable blinking

cca507c

ouellettetech requested changes Dec 27, 2019

View reviewed changes

greenbreakfast pushed a commit that referenced this pull request Feb 21, 2020

bringing in card manager stability fix from PR #6

86b7294

greenbreakfast closed this Feb 21, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Fix crash #6

Fix crash #6

X-Ryl669 commented Dec 21, 2019

ouellettetech left a comment

X-Ryl669 commented Dec 27, 2019

X-Ryl669 commented Dec 27, 2019 •

edited

Loading

ouellettetech commented Dec 27, 2019

greenbreakfast commented Jan 3, 2020

greenbreakfast commented Feb 21, 2020 •

edited

Loading

Fix crash #6

Fix crash #6

Conversation

X-Ryl669 commented Dec 21, 2019

ouellettetech left a comment

Choose a reason for hiding this comment

X-Ryl669 commented Dec 27, 2019

X-Ryl669 commented Dec 27, 2019 • edited Loading

ouellettetech commented Dec 27, 2019

greenbreakfast commented Jan 3, 2020

greenbreakfast commented Feb 21, 2020 • edited Loading

X-Ryl669 commented Dec 27, 2019 •

edited

Loading

greenbreakfast commented Feb 21, 2020 •

edited

Loading