[CM] snd 20.4, f32 segfault

[James Hearon]

Hi,
I'm having a strange problem after upgrading to f32 from f31.
I needed to rebuild snd because of a libgsl issue.

./snd: error while loading shared libraries: libgsl.so.23: cannot open shared object file: No such file or directory

Trying to rebuild with fresh srcs.

./configure  --with-s7 --with-gsl --with-alsa --without-gui

It builds, but when I try to run >./snd, I get a segfault.

[jhearon at dhcp-168-105-83-235 snd-20-command]$ ./snd
writing libc_s7.c
loading libc_s7.so
Segmentation fault (core dumped)

I'm not exactly sure what's going on.

I'm including a valgrind output, if that helps.

Regards,
Jim

[jhearon at dhcp-168-105-83-235 snd-20-command]$ valgrind ./snd
==11749== Memcheck, a memory error detector
==11749== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==11749== Using Valgrind-3.16.0 and LibVEX; rerun with -h for copyright info
==11749== Command: ./snd
==11749==
loading libc_s7.so
==11749== Invalid write of size 4
==11749==    at 0x46D1A7: add_opt_func (s7.c:60763)
==11749==    by 0x46D1A7: s7_set_i_ii_function (s7.c:60840)
==11749==    by 0x6555990: libc_s7_init (in /home/jhearon/libc_s7.so)
==11749==    by 0x4E2D61: load_shared_object (s7.c:30010)
==11749==    by 0x4E2D61: load_shared_object (s7.c:29952)
==11749==    by 0x4E319B: g_load (s7.c:30184)
==11749==    by 0x47049E: op_c_ss (s7.c:91384)
==11749==    by 0x47049E: eval.isra.0 (s7.c:93493)
==11749==    by 0x4E385E: s7_load_with_environment (s7.c:30130)
==11749==    by 0x4E3B2A: g_require (s7.c:30472)
==11749==    by 0x487596: apply_c_macro (s7.c:86109)
==11749==    by 0x46E172: eval.isra.0 (s7.c:94049)
==11749==    by 0x4E385E: s7_load_with_environment (s7.c:30130)
==11749==    by 0x6864A8: snd_doit (snd-nogui.c:724)
==11749==    by 0x422699: main (snd.c:629)
==11749==  Address 0x180001c9 is not stack'd, malloc'd or (recently) free'd
==11749==
==11749==
==11749== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==11749==  Access not within mapped region at address 0x180001C9
==11749==    at 0x46D1A7: add_opt_func (s7.c:60763)
==11749==    by 0x46D1A7: s7_set_i_ii_function (s7.c:60840)
==11749==    by 0x6555990: libc_s7_init (in /home/jhearon/libc_s7.so)
==11749==    by 0x4E2D61: load_shared_object (s7.c:30010)
==11749==    by 0x4E2D61: load_shared_object (s7.c:29952)
==11749==    by 0x4E319B: g_load (s7.c:30184)
==11749==    by 0x47049E: op_c_ss (s7.c:91384)
==11749==    by 0x47049E: eval.isra.0 (s7.c:93493)
==11749==    by 0x4E385E: s7_load_with_environment (s7.c:30130)
==11749==    by 0x4E3B2A: g_require (s7.c:30472)
==11749==    by 0x487596: apply_c_macro (s7.c:86109)
==11749==    by 0x46E172: eval.isra.0 (s7.c:94049)
==11749==    by 0x4E385E: s7_load_with_environment (s7.c:30130)
==11749==    by 0x6864A8: snd_doit (snd-nogui.c:724)
==11749==    by 0x422699: main (snd.c:629)
==11749==  If you believe this happened as a result of a stack
==11749==  overflow in your program's main thread (unlikely but
==11749==  possible), you can try to increase the size of the
==11749==  main thread stack using the --main-stacksize= flag.
==11749==  The main thread stack size used in this run was 8388608.
==11749==
==11749== HEAP SUMMARY:
==11749==     in use at exit: 11,644,308 bytes in 2,671 blocks
==11749==   total heap usage: 3,392 allocs, 721 frees, 11,951,327 bytes allocated
==11749==
==11749== LEAK SUMMARY:
==11749==    definitely lost: 0 bytes in 0 blocks
==11749==    indirectly lost: 0 bytes in 0 blocks
==11749==      possibly lost: 933,221 bytes in 1,939 blocks
==11749==    still reachable: 10,711,087 bytes in 732 blocks
==11749==         suppressed: 0 bytes in 0 blocks
==11749== Rerun with --leak-check=full to see details of leaked memory
==11749==
==11749== For lists of detected and suppressed errors, rerun with: -s
==11749== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Segmentation fault (core dumped)



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cm-mail.stanford.edu/mailman/private/cmdist/attachments/20200611/01a5a1a6/attachment.html>