Re: [hatari-devel] Fixing some STE sound issue and doing 2.4.1 release

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

Le 29/07/2022 à 16:20, Nicolas Pomarède a écrit :
> but tests are still failing for me (many more than in your cases). They 
> all report this :
>
> Direct leak of 920 byte(s) in 5 object(s) allocated from:
>      #0 0x7f562d0b8757 in calloc (/lib64/libasan.so.8+0xb8757)
>      #1 0x7f562bacb4df 
> (/home/npomarede/src/hatari.git/src/hatari+0x78984df)
>
> Direct leak of 520 byte(s) in 13 object(s) allocated from:
>      #0 0x7f562d0b8d6f in __interceptor_malloc 
> (/lib64/libasan.so.8+0xb8d6f)
>      #1 0x7f562bae4593 
> (/home/npomarede/src/hatari.git/src/hatari+0x78b1593)
>
> Direct leak of 96 byte(s) in 3 object(s) allocated from:
>      #0 0x7f562d0b8d6f in __interceptor_malloc 
> (/lib64/libasan.so.8+0xb8d6f)
>      #1 0x7f562badbdce 
> (/home/npomarede/src/hatari.git/src/hatari+0x78a8dce)
>
> Direct leak of 24 byte(s) in 1 object(s) allocated from:
>      #0 0x7f562d0b8d6f in __interceptor_malloc 
> (/lib64/libasan.so.8+0xb8d6f)
>      #1 0x7f562badda91 
> (/home/npomarede/src/hatari.git/src/hatari+0x78aaa91)
>
> Indirect leak of 1198 byte(s) in 7 object(s) allocated from:
>      #0 0x7f562d0b7c75 in __interceptor_realloc.part.0 
> (/lib64/libasan.so.8+0xb7c75)
>      #1 0x7f562badded4 
> (/home/npomarede/src/hatari.git/src/hatari+0x78aaed4)
>
> Indirect leak of 120 byte(s) in 3 object(s) allocated from:
>      #0 0x7f562d0b8d6f in __interceptor_malloc 
> (/lib64/libasan.so.8+0xb8d6f)
>      #1 0x7f562baddfa3 
> (/home/npomarede/src/hatari.git/src/hatari+0x78aafa3)
>
> Indirect leak of 24 byte(s) in 1 object(s) allocated from:
>      #0 0x7f562d0b8d6f in __interceptor_malloc 
> (/lib64/libasan.so.8+0xb8d6f)
>      #1 0x7f562badda91 
> (/home/npomarede/src/hatari.git/src/hatari+0x78aaa91)
>
> Indirect leak of 24 byte(s) in 1 object(s) allocated from:
>      #0 0x7f562d0b8d6f in __interceptor_malloc 
> (/lib64/libasan.so.8+0xb8d6f)
>      #1 0x7f562baddae5 
> (/home/npomarede/src/hatari.git/src/hatari+0x78aaae5)
>
> unfortunately, there's no indication of what part of th code it is.

And for the -vdi tests, I see this :
==29173==ERROR: AddressSanitizer: heap-buffer-overflow on address 
0x7f5c0aa73840 at pc 0x0000006e5611 bp 0x7fffd2b6b690 sp 0x7fffd2b6b688
READ of size 4 at 0x7f5c0aa73840 thread T0
    #0 0x6e5610 in Screen_BitplaneToChunky32 
/home/npomarede/src/hatari.git/src/screenConvert.c:205
    #1 0x6e93c9 in ScreenConv_BitplaneLineTo32bpp 
/home/npomarede/src/hatari.git/src/screenConvert.c:342
    #2 0x6e93c9 in ScreenConv_BitplaneTo32bppNoZoom 
/home/npomarede/src/hatari.git/src/screenConvert.c:453
    #3 0x6e93c9 in Screen_ConvertWithoutZoom 
/home/npomarede/src/hatari.git/src/screenConvert.c:680
    #4 0x6e93c9 in Screen_GenConvert 
/home/npomarede/src/hatari.git/src/screenConvert.c:1146
    #5 0x6ea727 in Screen_GenDraw 
/home/npomarede/src/hatari.git/src/screenConvert.c:1166
    #6 0x7142bd in Video_DrawScreen 
/home/npomarede/src/hatari.git/src/video.c:4399
    #7 0x7142bd in Video_InterruptHandler_VBL 
/home/npomarede/src/hatari.git/src/video.c:4577
    #8 0x7fbe9c in CycInt_Process 
/home/npomarede/src/hatari.git/src/includes/cycInt.h:130
    #9 0x7fbe9c in do_specialties 
/home/npomarede/src/hatari.git/src/cpu/newcpu.c:4971
    #10 0x8029f8 in m68k_run_1_ce 
/home/npomarede/src/hatari.git/src/cpu/newcpu.c:5449
    #11 0x7f3659 in m68k_go 
/home/npomarede/src/hatari.git/src/cpu/newcpu.c:7614
    #12 0x5c6b35 in main /home/npomarede/src/hatari.git/src/main.c:969
    #13 0x7f5c0ce30176 in __libc_start_call_main (/lib64/libc.so.6+0x29176)
    #14 0x7f5c0ce30234 in __libc_start_main_alias_1 
(/lib64/libc.so.6+0x29234)
    #15 0x5c9430 in _start 
(/home/npomarede/src/hatari.git/src/hatari+0x5c9430)

0x7f5c0aa73840 is located 0 bytes to the right of 4251712-byte region 
[0x7f5c0a665800,0x7f5c0aa73840)
allocated by thread T0 here:
    #0 0x7f5c0d6b8757 in calloc (/lib64/libasan.so.8+0xb8757)
    #1 0x8575e0 in memory_init 
/home/npomarede/src/hatari.git/src/cpu/memory.c:1676
    #2 0x6fa846 in TOS_InitImage 
/home/npomarede/src/hatari.git/src/tos.c:1135
    #3 0x6c33b1 in Reset_ST /home/npomarede/src/hatari.git/src/reset.c:61
    #4 0x5c6528 in Main_Init /home/npomarede/src/hatari.git/src/main.c:757
    #5 0x5c6528 in main /home/npomarede/src/hatari.git/src/main.c:951
    #6 0x7f5c0ce30176 in __libc_start_call_main (/lib64/libc.so.6+0x29176)

SUMMARY: AddressSanitizer: heap-buffer-overflow 
/home/npomarede/src/hatari.git/src/screenConvert.c:205 in 
Screen_BitplaneToChunky32
Shadow bytes around the buggy address:
  0x0fec015466b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0fec015466c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0fec015466d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0fec015466e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0fec015466f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0fec01546700: 00 00 00 00 00 00 00 00[fa]fa fa fa fa fa fa fa
  0x0fec01546710: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0fec01546720: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0fec01546730: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0fec01546740: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0fec01546750: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb


I'm not familiar with Screen_BitplaneToChunky32(), can't tell if it's a 
false positive due to the various casts used to convert screen.

Nicolas