After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 695883 - Crash while allocating memory?
Crash while allocating memory?
Status: RESOLVED OBSOLETE
Product: glib
Classification: Platform
Component: gobject
2.34.x
Other Linux
: Normal normal
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2013-03-14 22:06 UTC by Vladimír Čunát
Modified: 2017-10-06 10:37 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Vladimír Čunát 2013-03-14 22:06:52 UTC 
I'm getting a crash in midori; the backtrace seems glib-related.

More details: I'm fixing packages in an experimental distro (nixos.org), currently we're having crashes in webkit browsers at the moment of first displaying a page. However, the backtrace is full of glib (and glibc). It could also be a glibc problem, both glib and glibc are in quite recent (but "stable/released") versions. Perhaps you can decode this.

The version of glib is 2.34.3. The strange hashed paths are normal for us and shouldn't cause this. I just guessed the component as gobject.

I'll happily supply any information you need, just ask.

+ Trace 231645

  • #0 raise
    from /nix/store/zpr8jdx10napidkyz62f3nzl5fm87jyr-glibc-2.17/lib/libc.so.6
  • #1 abort
    from /nix/store/zpr8jdx10napidkyz62f3nzl5fm87jyr-glibc-2.17/lib/libc.so.6
  • #2 g_logv
    at gmessages.c line 969
  • #3 g_log
    at gmessages.c line 1003
  • #4 g_malloc0
    at gmem.c line 194
  • #5 thread_memory_from_self
    at gslice.c line 512
  • #6 thread_memory_from_self
    at gslice.c line 501
  • #7 g_slice_alloc
    at gslice.c line 981
  • #8 g_string_sized_new
    at gstring.c line 126
  • #9 g_log_default_handler
    at gmessages.c line 1322
  • #10 g_logv
    at gmessages.c line 945
  • #11 g_log
    at gmessages.c line 1003
  • #12 g_malloc0
    at gmem.c line 194
  • #13 thread_memory_from_self
    at gslice.c line 512
  • #14 thread_memory_from_self
    at gslice.c line 501
  • #15 g_slice_free1
    at gslice.c line 1087
  • #16 g_queue_pop_tail
    at gqueue.c line 632
  • #17 g_async_queue_pop_intern_unlocked
    at gasyncqueue.c line 431
  • #18 g_thread_pool_wait_for_new_task
    at gthreadpool.c line 264
  • #19 g_thread_pool_thread_proxy
    at gthreadpool.c line 298
  • #20 g_thread_proxy
    at gthread.c line 797
  • #21 start_thread
    from /nix/store/zpr8jdx10napidkyz62f3nzl5fm87jyr-glibc-2.17/lib/libpthread.so.0
  • #22 clone
    from /nix/store/zpr8jdx10napidkyz62f3nzl5fm87jyr-glibc-2.17/lib/libc.so.6 






Comment 1


Vladimír Čunát





          2013-03-14 23:10:15 UTC
        



Update: uzbl sigsegvs in webkit's WTF::fastMalloc(unsigned long), so it seems like a memory-allocation issue, probably not related to glib. I'll be glad for any hints what to do with this anyway...






Comment 2


Philip Withnall





          2017-10-06 10:37:27 UTC
        



That backtrace indicates that the calloc() call failed. It could be that you were out of memory, or the heap was corrupted. I suggest running the program under valgrind’s memcheck tool to check for corruption first.

However, since this bug is 4.5 years old, I’m going to close it since it’s unlikely there’s anything we can do here. If, somehow, you can still reliably reproduce the bug please re-open this report.