[arch-general] Debugging third-party library's segfault if its caused by system update?

[Oon-Ee Ng]

On Fri, Jun 12, 2015 at 2:25 PM, Lars Seipel <lars.seipel at gmail.com> wrote:
>
> Try running a small program using the library in valgrind. The output
> should provide you with some hints. GDB (like Florian suggested) is also
> an option but, personally, I find valgrind a bit more convenient for
> such first quick checks. It also flags invalid memory accesses that do
> not cause your program to get killed.

Tried that, and the error comes in a thread reading an uninitialized
pointer (I believe, valgrind output shown below). This isn't the sort
of error which should be triggered by upgrading a different package
though, is it?

Which leads to my follow-up question, how likely is it that a glibc
update causes a crash?

==10236== Using Valgrind-3.10.1 and LibVEX; rerun with -h for
copyright info

                            [13/20]
==10236== Command: SimpleViewer
==10236==
==10236== Thread 3:
==10236== Invalid read of size 1
==10236==    at 0x59E9784: ____strtoul_l_internal (in /usr/lib/libc-2.21.so)
==10236==    by 0xA654637: ??? (in /usr/lib/OpenNI2/Drivers/libPS1080.so)
==10236==    by 0xA654BD8: ??? (in /usr/lib/OpenNI2/Drivers/libPS1080.so)
==10236==    by 0x90CE353: start_thread (in /usr/lib/libpthread-2.21.so)
==10236==    by 0x5A99BFC: clone (in /usr/lib/libc-2.21.so)
==10236==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==10236==
==10236==
==10236== Process terminating with default action of signal 11
(SIGSEGV): dumping core
==10236==  Access not within mapped region at address 0x0
==10236==    at 0x59E9784: ____strtoul_l_internal (in /usr/lib/libc-2.21.so)
==10236==    by 0xA654637: ??? (in /usr/lib/OpenNI2/Drivers/libPS1080.so)
==10236==    by 0xA654BD8: ??? (in /usr/lib/OpenNI2/Drivers/libPS1080.so)
==10236==    by 0x90CE353: start_thread (in /usr/lib/libpthread-2.21.so)
==10236==    by 0x5A99BFC: clone (in /usr/lib/libc-2.21.so)
==10236==  If you believe this happened as a result of a stack
==10236==  overflow in your program's main thread (unlikely but
==10236==  possible), you can try to increase the size of the
==10236==  main thread stack using the --main-stacksize= flag.
==10236==  The main thread stack size used in this run was 8388608.
==10236==
==10236== HEAP SUMMARY:
==10236==     in use at exit: 284,816 bytes in 1,875 blocks
==10236==   total heap usage: 6,845 allocs, 4,970 frees, 2,388,919
bytes allocated