1

I created a program fairly closely related to hello_pi/hello_video.c. And for some reason after several hours of running the program I get these very strange segfaults that I cannot for the life of me figure out how to resolve. Here is what I am running:

  • Raspberry PI 3B+
  • Raspbian Lite (Buster)

I have checked the following:

  • I am not under voltage. I am using a 5.1v 2.5a power supply from raspberry PI themselves.
  • I did not over clock the system. I am sitting at 1.4 like a normal PI.
  • The system has heat sinks and a fan to keep the temperature low.
  • The system is also totally up to date (apt update... upgrade... rpi-update etc)

Here are a few of the errors I am receiving from the address sanitizer built into gcc:

==26987==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x45009021 at pc 0x769ca548 bp 0x5a7fa474 sp 0x5a7fa040
READ of size 8 at 0x45009021 thread T450 (ILCS_HOST)
    #0 0x769ca547  (/usr/lib/arm-linux-gnueabihf/libasan.so.5+0x3a547)

Address 0x45009021 is a wild pointer.
SUMMARY: AddressSanitizer: heap-buffer-overflow (/usr/lib/arm-linux-gnueabihf/libasan.so.5+0x3a547) 
Shadow bytes around the buggy address:
  0x28a011b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x28a011c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x28a011d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x28a011e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x28a011f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
=>0x28a01200: fa fa fa fa[fa]fa fa fa fa fa fa fa fa fa fa fa
  0x28a01210: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x28a01220: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x28a01230: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x28a01240: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x28a01250: 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
Thread T450 (ILCS_HOST) created by T443 here:
    #0 0x769db9c7 in pthread_create (/usr/lib/arm-linux-gnueabihf/libasan.so.5+0x4b9c7)
    #1 0x7693b203 in vcos_thread_create /home/dom/projects/staging/userland/interface/vcos/pthreads/vcos_pthreads.c:212

Thread T443 created by T0 here:
    #0 0x769db9c7 in pthread_create (/usr/lib/arm-linux-gnueabihf/libasan.so.5+0x4b9c7)
    #1 0x74ee1c57 in std::thread::_M_start_thread(std::unique_ptr<std::thread::_State, std::default_delete<std::thread::_State> >, void (*)()) (/usr/lib/arm-linux-gnueabihf/libstdc++.so.6+0x9dc57)
    #2 0x6bb02a7f  (<unknown module>)

==26987==ABORTING

==23420==ERROR: AddressSanitizer: SEGV on unknown address 0x0019c2c0 (pc 0x74b060f0 bp 0x74b08f3c sp 0x6acfe3b8 T2)
==23420==The signal is caused by a READ memory access.
    #0 0x74b060ef in completion_thread (/opt/vc/lib/libvchiq_arm.so+0x20ef)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV (/opt/vc/lib/libvchiq_arm.so+0x20ef) in completion_thread
Thread T2 (VCHIQ completio) created by T0 here:
    #0 0x769609c7 in pthread_create (/usr/lib/arm-linux-gnueabihf/libasan.so.5+0x4b9c7)
    #1 0x768c0203 in vcos_thread_create /home/dom/projects/staging/userland/interface/vcos/pthreads/vcos_pthreads.c:212

==23420==ABORTING

Here is the output from gdb during those crashes:

Thread 3 "VCHIQ completio" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x6fbfeb00 (LWP 15664)]
0x751c60f0 in completion_thread () from /opt/vc/lib/libvchiq_arm.so

All the crashes seem to be related to "completion_thread()". I have no idea what that is.

Any help would be greatly appreciated!

  • 1
    Almost sounds like a memory leak. Watch it for a while and see if it's virtual size increases without bound. This unknownroad.com/rtfm/gdbtut/gdbsegfault.html looks like it might be helpful in gdb. – bls Jul 22 at 21:08
  • I take it you have based this on some example code. Does the example code crash in the same way? If it doesn't you need to find the bug you have added. – joan Jul 22 at 21:09
  • @bls well I have checked the memory usage and that does not increase over time. So I am not sure it is a memory leak – ktb92677 Jul 22 at 21:26
  • @joan I have based on many bits and pieces of sample code from all over. I am sure I am the one who added the issue but it is extremely odd that neither the sanitizer not gdb say that the actual error is in my code. – ktb92677 Jul 22 at 21:28
  • 1
    You need to find out when you introduced the bug. Start from the base example and make changes until it starts crashing again. That will localise where you introduced the bug. – joan Jul 23 at 9:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.