Re: Urgent: Balsa crashes on send / how to debug



Hi Albrecht,
thanks for the suggestions but valgrinds output doesn't say much to me:

=859== Memcheck, a memory error detector
=859== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
=859== Using Valgrind-3.12.0 and LibVEX; rerun with -h for copyright info
=859== Command: src/balsa
=859== Parent PID: 2090
=859==859== Thread 7:
=859== Syscall param write(buf) points to uninitialised byte(s)
=859==    at 0xBBDEFF4: write (in /lib64/libpthread-2.26.so)
=859==    by 0xB4EB214: write_to_temp_file (in /usr/lib64/libglib-2.0.so.0.5200.3)
=859==    by 0x20BBD96F: ???
=859==  Address 0x1caaa254 is 512,884 bytes inside a block of size 524,288 alloc'd
=859==    at 0x4C2DE8F: malloc (vg_replace_malloc.c:298)
=859==    by 0x4C30254: realloc (vg_replace_malloc.c:785)
=859==    by 0xB504C9F: g_realloc (in /usr/lib64/libglib-2.0.so.0.5200.3)
=859==    by 0x7FFFF: ???
=859==    by 0xB4D0DB8: g_array_maybe_expand (in /usr/lib64/libglib-2.0.so.0.5200.3)
=859==859== Thread 1:
=859== Invalid read of size 8
=859==    at 0xB4FE8A7: g_main_context_prepare (in /usr/lib64/libglib-2.0.so.0.5200.3)
=859==    by 0xF00000000: ???
=859==    by 0x19FB350F: ???
=859==    by 0x1CDEC54F: ???
=859==    by 0x1FA05DFB: ???
=859==    by 0xCAE39A4EB8AF4FFF: ???
=859==    by 0x27: ???
=859==    by 0x19DF8B8F: ???
=859==    by 0x1FA05E8F: ???
=859==    by 0x1D1B0DEF: ???
=859==    by 0xFFEFFE9A3: ???
=859==  Address 0x22552880 is not stack'd, malloc'd or (recently) free'd
=859==859==859== Process terminating with default action of signal 11 (SIGSEGV)
=859==  Access not within mapped region at address 0x22552880
=859==    at 0xB4FE8A7: g_main_context_prepare (in /usr/lib64/libglib-2.0.so.0.5200.3)
=859==    by 0xF00000000: ???
=859==    by 0x19FB350F: ???
=859==    by 0x1CDEC54F: ???
=859==    by 0x1FA05DFB: ???
=859==    by 0xCAE39A4EB8AF4FFF: ???
=859==    by 0x27: ???
=859==    by 0x19DF8B8F: ???
=859==    by 0x1FA05E8F: ???
=859==    by 0x1D1B0DEF: ???
=859==    by 0xFFEFFE9A3: ???
=859==  If you believe this happened as a result of a stack
=859==  overflow in your program's main thread (unlikely but
=859==  possible), you can try to increase the size of the
=859==  main thread stack using the --main-stacksize= flag.
=859==  The main thread stack size used in this run was 8388608.
=859==859== HEAP SUMMARY:
=859==     in use at exit: 10,194,758 bytes in 130,001 blocks
=859==   total heap usage: 754,029 allocs, 624,028 frees, 77,839,508 bytes allocated
=859==859== LEAK SUMMARY:
=859==    definitely lost: 25,144 bytes in 152 blocks
=859==    indirectly lost: 44,223 bytes in 2,082 blocks
=859==      possibly lost: 9,595 bytes in 113 blocks
=859==    still reachable: 8,635,020 bytes in 117,130 blocks
=859==                       of which reachable via heuristic:
=859==                         length64           : 13,560 bytes in 195 blocks
=859==                         newarray           : 2,384 bytes in 69 blocks
=859==         suppressed: 0 bytes in 0 blocks
=859== Rerun with --leak-check=full to see details of leaked memory
=859==859== For counts of detected and suppressed errors, rerun with: -v
=859== Use --track-origins=yes to see where uninitialised values come from
=859== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]