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@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@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)
_______________________________________________ Cmdist mailing list [email protected] https://cm-mail.stanford.edu/mailman/listinfo/cmdist
