crash on closing document: SIGSEGV in malloc_consolidate (av=0x7ffff1165ec0) at malloc.c:5155

Bug #909687 reported by Sasa Paporovic on 2011-12-29
This bug affects 1 person
Affects Status Importance Assigned to Milestone

Bug Description

I´am on openSUSE12.1 64bit with inkscape0.48.2.

I´ve just closed a document(not the inkscape). The crash happens immediately.

I´ve a stacktrace here that shows:

Program received signal SIGSEGV, Segmentation fault.
malloc_consolidate (av=0x7ffff1165ec0) at malloc.c:5155
5155 nextsize = chunksize(nextchunk);

I attach a stacktrace.

Sasa Paporovic (melchiaros) wrote :
Sasa Paporovic (melchiaros) wrote :

Well, this is a serious think, because it seems to also affect linux kernel internals with:

#90 0x00000000006842b0 in sp_main_gui (argc=1, argv=0x7fffffffdd28) at main.cpp:979
#91 0x00000000006697a8 in main (argc=1, argv=0x7fffffffdd28) at main.cpp:715
(gdb) continue

Emergency save activated!
Program received signal SIGINT, Interrupt.
__lll_lock_wait_private () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:93
93 2: movl %edx, %eax
(gdb) thread apply all bt

Thread 1 (Thread 0x7ffff7fa89a0 (LWP 8910)):
#0 __lll_lock_wait_private () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:93
#1 0x00007ffff0e55d21 in _L_lock_9946 () at malloc.c:6487

Sasa Paporovic (melchiaros) wrote :

I will attach the further stacktrace of this.

Please tell me if you think that is only a problem of inkscape, or kernel developers should also get a report.

Sasa Paporovic (melchiaros) wrote :
Sasa Paporovic (melchiaros) wrote :

inkscape hangs with the last as a complete grey window on my desktop and is not able to terminate as it was introduced by SIGSEV.

Alex Valavanis (valavanisalex) wrote :

Is this reproducible, or did it just happen once? Please could you attach the document that causes the problem?

Changed in inkscape:
status: New → Incomplete
importance: Undecided → High
tags: added: crash
Sasa Paporovic (melchiaros) wrote :

Mhh, where is the difference between:

"Menu-> File -> Close"



I´ve choosed for this bug "Close" and thought that it only close the document, and not inkscape itself.
But a chceck has shown me that both options closes inkscape(this time normal in both cases).

Anyway the report here is not affected of this.

Reproducing at this time is not possible to me.

su_v (suv-lp) wrote :

> where is the difference between (…)

'FIle > Close' closes the current document window (you can open multiple documents from within the same inkscape instance). If you have only a single document window open, the command closes the window and quits Inkscape (since Inkscape is document-oriented, the application does not stay open without any open document window).

'File > Quit' closes all open document windows and quits Inkscape

(see also bug #170550, comment #1).

Sasa Paporovic (melchiaros) wrote :

in reply to comment #6:

Simple reproducing with a document filling in a see the crash is not given here.

I´ve worked on this document(not very greatful), do various things in the inkscape settings and used than after inkscape had run for a while "Menu->File->Close".

Emergency saving has failed as you can see on comment #2. So also getting out the last working state that might be near to causing the crash(beside other possibilities) is not possible.
 [->this together makes the crash critical because of complete data lose.]

When I hit it again, I post it here.

I attach the original file, but as I pointed out: It will not help.

BTW: What is your opinion to:

__lll_lock_wait_private () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:93
93 2: movl %edx, %eax

Is it more to inkscape or more to kernel?

Sasa Paporovic (melchiaros) wrote :
Changed in inkscape:
status: Incomplete → New
Bryce Harrington (bryce) wrote :

This section of the stacktrace looks interesting, although it doesn't inform me as to why it's crashing:

> #64 0x00007ffff5364240 in g_object_run_dispose (object=0x4d299e0 [gtkmm__GtkWindow]) at gobject.c:945
> #65 0x00007ffff7ab10f1 in Gtk::Window::~Window (this=0x4d46480, __in_chrg=<optimized out>, __vtt_parm=<optimized out>) at
> #66 0x00007ffff7ab11d9 in Gtk::Window::~Window (this=0x4d46480, __in_chrg=<optimized out>, __vtt_parm=<optimized out>) at
> #67 0x00000000008f0f3a in SPDesktopWidget::WidgetStub::destroy (this=0x2e8f1d0) at widgets/desktop-widget.h:156
> #68 0x000000000082fed2 in sp_action_perform (action=0x1bee770, data=0x0) at helper/action.cpp:181

The window is being destroyed but something deeper in gtk signal handling code is wanting to fiddle with memory management. It's not a kernel bug. Possibly a bug in gtk.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers