Bug#331400: aptitude segfaults during dist-upgrade
Daniel Burrows wrote: Ah, thanks. I found a bit of code that's definitely wrong, and it may even be causing your crash (thank goodness I put those asserts in, or you'd have gotten random memory corruption later on). Could you try the attached patch and see if the crash goes away? Yay! No more crash! Thanks! Tom -- [EMAIL PROTECTED] - http://tevp.net Illegitimus non carborundum -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#331400: aptitude segfaults during dist-upgrade
Daniel Burrows wrote: I think a backtrace really would help, since that would give me a clue which widget is being hauled out of its grave...I'll try some more combinations of packages and see if I can reproduce it here, too. I'm now able to trigger it by starting aptitude without any arguments, selecting a version of a package that breaks something, pressing 'g' to bring up the solutions dialog, and attempting to apply the first solution that I get given. Tried recompiling aptitude with CXXFLAGS=-O0 -g set in order to get rid of the optimizing away that was hiding some of the information about the program stack, and got the attached stack trace screenshot. Hopefully it'll be of a bit more use... Tom -- [EMAIL PROTECTED] - http://tevp.net Illegitimus non carborundum
Bug#331400: aptitude segfaults during dist-upgrade
On Mon, Oct 03, 2005 at 11:37:49AM +0200, Tom Parker wrote:
Sequence of events:
1) run aptitude dist-upgrade
2) get informed that because of conflicts, it can't upgrade
mozilla-thunderbird, press 'e' at Accept this solution prompt
3) Enter mozilla-thunderbird package, select later version of
libpng12-0 (1.2.8rel-4), now lets me upgrade thunderbird to 1.0.7-1
4) Press 'g' at resolve dependancies screen, and accept the solution
that's been created
5) segfault!
Looks like this assert is tripping:
void decref()
{
assert(refcount 0);
--refcount;
if(refcount == 0)
cleanup();
}
The actual line number that this was invoked from got optimized away,
but it probably happens when solution_dialog::update() exits and the
smart pointer to 'this' is destroyed.
Could you apply the attached patch (which adds an assert to balance
the other one -- the only widget with a zero reference count is a dead
widget ;-) ) and see if it crashes in a different place? If not, something
highly screwy is happening.
Daniel
Mon Oct 3 19:21:06 PDT 2005 Daniel Burrows [EMAIL PROTECTED]
* Disallow (assert against) the creation of strong references to widgets with
a zero reference count.
Since widgets are now created with a reference count of 1, it is now an
invariant that every widget with a zero reference count is dead.
diff -rN -u old-aptitude/src/vscreen/vscreen_widget.h
new-aptitude/src/vscreen/vscreen_widget.h
--- old-aptitude/src/vscreen/vscreen_widget.h 2005-10-03 19:22:32.0
-0700
+++ new-aptitude/src/vscreen/vscreen_widget.h 2005-10-03 19:06:23.0
-0700
@@ -179,6 +179,8 @@
public:
void incref()
{
+assert(refcount 0);
+
++refcount;
}
Bug#331400: aptitude segfaults during dist-upgrade
On Thu, Oct 06, 2005 at 12:04:01PM +0200, Tom Parker [EMAIL PROTECTED] was
heard to say:
Daniel Burrows wrote:
I think a backtrace really would help, since that would give me a clue
which widget is being hauled out of its grave...I'll try some more
combinations of packages and see if I can reproduce it here, too.
I'm now able to trigger it by starting aptitude without any arguments,
selecting a version of a package that breaks something, pressing 'g' to
bring up the solutions dialog, and attempting to apply the first solution
that I get given.
Tried recompiling aptitude with CXXFLAGS=-O0 -g set in order to get rid
of the optimizing away that was hiding some of the information about the
program stack, and got the attached stack trace screenshot. Hopefully it'll
be of a bit more use...
Ah, thanks. I found a bit of code that's definitely wrong, and it may
even be causing your crash (thank goodness I put those asserts in, or
you'd have gotten random memory corruption later on). Could you try the
attached patch and see if the crash goes away?
Thanks,
Daniel
Thu Oct 6 11:19:02 PDT 2005 Daniel Burrows [EMAIL PROTECTED]
* Use a slot_event instead of a custom event type to post solution dialog
updates.
Aside from bringing this code into line with the current recommended way of
handling one-off events, this also avoids posting bare pointers to the event
queue when the underlying object might be deleted before the event is
dispatched (the alternative would be to make the update_event hold either
a weak or a strong reference, but this is obviously simpler).
diff -rN -u old-head/src/solution_dialog.cc new-head/src/solution_dialog.cc
--- old-head/src/solution_dialog.cc 2005-10-06 11:19:54.815119824 -0700
+++ new-head/src/solution_dialog.cc 2005-10-06 11:13:20.0 -0700
@@ -57,25 +57,9 @@
update();
}
- struct update_event : public vscreen_event
- {
-solution_dialog *dlg;
-
- public:
-update_event(solution_dialog *_dlg)
- :dlg(_dlg)
-{
-}
-
-void dispatch()
-{
- dlg-update();
-}
- };
-
void post_update()
{
-vscreen_post_event(new update_event(this));
+vscreen_post_event(new slot_event(sigc::mem_fun(this,
solution_dialog::update)));
}
protected:
signature.asc
Description: Digital signature
Bug#331400: aptitude segfaults during dist-upgrade
On Tue, Oct 04, 2005 at 03:06:18PM +0100, Tom Parker wrote: On 4/10/2005, Daniel Burrows [EMAIL PROTECTED] wrote: Could you apply the attached patch (which adds an assert to balance the other one -- the only widget with a zero reference count is a dead widget ;-) ) and see if it crashes in a different place? If not, something highly screwy is happening. It's now bugging out at vscreen_widget.h:182 (i.e. at the new assert) Sorry, I meant get a backtrace ;-). But at least that means that my guess is right -- a widget is dying and then a new reference is being constructed to it. Hm. Most likely that's in an event handler bound to a weak reference; but those should all be removed as soon as the widget is destroyed. I think a backtrace really would help, since that would give me a clue which widget is being hauled out of its grave...I'll try some more combinations of packages and see if I can reproduce it here, too. Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#331400: aptitude segfaults during dist-upgrade
On 4/10/2005, Daniel Burrows [EMAIL PROTECTED] wrote: Could you apply the attached patch (which adds an assert to balance the other one -- the only widget with a zero reference count is a dead widget ;-) ) and see if it crashes in a different place? If not, something highly screwy is happening. It's now bugging out at vscreen_widget.h:182 (i.e. at the new assert)
Bug#331400: aptitude segfaults during dist-upgrade
Package: aptitude Version: 0.3.4-1 Severity: important Sequence of events: 1) run aptitude dist-upgrade 2) get informed that because of conflicts, it can't upgrade mozilla-thunderbird, press 'e' at Accept this solution prompt 3) Enter mozilla-thunderbird package, select later version of libpng12-0 (1.2.8rel-4), now lets me upgrade thunderbird to 1.0.7-1 4) Press 'g' at resolve dependancies screen, and accept the solution that's been created 5) segfault! I rebuilt aptitude on my local machine to get a version with debug symbols, and was able to reproduce the same fault. Unfortunately, the terminal appears to have been messed up by the crash, and I can't just attach the text version of the stack. Instead, here's a screenshot of it... -- System Information: Debian Release: testing/unstable APT prefers stable APT policy: (990, 'stable'), (103, 'testing'), (102, 'unstable'), (99, 'experimental'), (98, 'hoary'), (97, 'breezy') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12-1-686-smp Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages aptitude depends on: ii apt [libapt-pkg-libc6.3-6-3.1 0.6.41 Advanced front-end for dpkg ii libc6 2.3.5-6GNU C Library: Shared libraries an ii libgcc1 1:4.0.2-2 GCC support library ii libncursesw5 5.4-9 Shared libraries for terminal hand ii libsigc++-2.0-0c2 2.0.10-3 type-safe Signal Framework for C++ ii libstdc++64.0.2-2The GNU Standard C++ Library v3 Versions of packages aptitude recommends: pn aptitude-doc-en | aptitude-do none (no description available) -- no debconf information aptitude-bt1.png Description: PNG image
