Re: Urgent: Balsa crashes on send / how to debug
- From: Helmut Jarausch <jarausch skynet be>
- To: Albrecht Dreß <albrecht dress arcor de>
- Cc: balsa-list gnome org
- Subject: Re: Urgent: Balsa crashes on send / how to debug
- Date: Mon, 11 Sep 2017 16:54:33 -0000
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]