Bug#461761: aptitude: segfaults when accessing options
First of all: On Mon, 2008-03-31 at 07:00 -0700, Daniel Burrows wrote: Does 0.4.11.1-1 segfault for you? Ha! No, it doesn't segfault anymore! It appears to have fixed itself... No idea how, though. On Mon, Mar 31, 2008 at 12:20:07PM +0200, Bram Senders [EMAIL PROTECTED] was heard to say: To be sure that the patch what fixes it, I de-applied it and make again... but now aptitude still doesn't segfault! Hmm. It doesn't segfault anymore either with or without the patch. Maybe it's the build options? I try a straight debuild -- without your patch, and without any CXXFLAGS, and install that package, run it... no segfault on preferences! Install the exact same version (0.4.11-3) from the Debian archive... and it segfaults on preferences! Now I am very confused. That's weird and disturbing. Unfortunately, I have no idea how the Debian package for powerpc was built, since it's compiled on an autobuilder. The only thing I can think of is that maybe it was built against an incompatible library: for instance, libsigc++-2.0 could have changed its ABI without upstream bumping the SONAME (easy to do by accident with C++ libraries). If this was the case, though, I'd expect aptitude to segfault all over, not just in the preferences screen. Hmm. Yes. Maybe that was it... BTW: when you installed your hand-built package, you're sure you were running that and not some other version? i.e., if you ran make install to install aptitude systemwide, you'll need to remove it to get it out of $PATH. Yes, I did take care of that :-) Well, umm, I guess this bug can be closed, then, even though we are not sure what the cause was? Cheers, Bram -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#461761: aptitude: segfaults when accessing options
On Sun, 2008-03-30 at 09:39 -0700, Daniel Burrows wrote: On Sun, Mar 30, 2008 at 01:46:47PM +0200, Bram Senders [EMAIL PROTECTED] was heard to say: ==5065== Invalid read of size 1 ==5065==at 0xFFBBC7C: strlen (mc_replace_strmem.c:242) ==5065==by 0xF6593D4: __dcigettext (dcigettext.c:456) ==5065==by 0xF658290: dcgettext (dcgettext.c:53) ==5065==by 0x100F9F4C: add_menu(cwidget::widgets::menu_info*, std::string const, cwidget::util::ref_ptrcwidget::widgets::label const) (ui.cc:2385) (...) So, all this stuff in the menu code is due to a bug in ui.cc: it stores a reference to a temporary string and then reads from it. The attached patch fixes this, but I doubt it's the problem you're seeing: reading from bad memory shouldn't cause corruption later on. ==5065== Invalid read of size 4 ==5065==at 0xFDCA7EC: cwidget::widgets::widget::widget() (limit_reference.h:81) And we crash. The code at this point is just connecting some signals to this as far as I can tell, and in fact the line of code that's referenced above is just initializing a reference without even casting it! That shouldn't crash unless this somehow became NULL, but the address valgrind reports isn't NULL. Can you compile the program with CXXFLAGS=-g -O0 -fno-inline ./configure make Ah, the segmentation fault now does not happen anymore, and I can access the preferences, nice! I do get a message from aptitude at the beginning stating │E: Opening configuration file /usr/local/share/aptitude/aptitude-defaults - ▒│ │ ifstream::ifstream (2 No such file or directory) ▒│ │E: Opening configuration file /usr/local/share/aptitude/section-descriptions ▒│ │ - ifstream::ifstream (2 No such file or directory)▒│ but I suspect that is harmless, right? To be sure that the patch what fixes it, I de-applied it and make again... but now aptitude still doesn't segfault! Hmm. It doesn't segfault anymore either with or without the patch. Maybe it's the build options? I try a straight debuild -- without your patch, and without any CXXFLAGS, and install that package, run it... no segfault on preferences! Install the exact same version (0.4.11-3) from the Debian archive... and it segfaults on preferences! Now I am very confused. Anyways, the two binaries (one built myself with debuild, and the other from the archive) differ a bit in size anyways: -rwxr-xr-x 1 bram bram 2287728 2008-03-31 11:48 aptitude-debuild-nopatch -rwxr-xr-x 1 bram bram 2807768 2008-03-31 11:48 aptitude-debian-archive , and a binary diff reveals that they are very different (that may not mean much, I don't know, I don't have experience with these things). aptitude-debuild-nopatch doesn't segfault on preferences, aptitude-debian-archive does. and valgrind the result? I have attached two valgrindings from the aptitude I built myself, the first one (aptitude-built-myself-with-patch.grind) with your patch applied and built with CXXFLAGS=-g -O0 -fno-inline ./configure make , the second one (aptitude-debuild-nopatch.grind) with the straight debuild from source. Again, for the record, neither segfaults on preferences. Is there any way in which I can debug / find out why debuilding myself doesn't segfault, but the package from the Debian archive does? Cheers, Bram ==11016== Memcheck, a memory error detector. ==11016== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al. ==11016== Using LibVEX rev 1804, a library for dynamic binary translation. ==11016== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP. ==11016== Using valgrind-3.3.0-Debian, a dynamic binary instrumentation framework. ==11016== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al. ==11016== For more details, rerun with: -v ==11016== ==11016== My PID = 11016, parent PID = 4345. Prog and args are: ==11016==./aptitude-built-myself-with-patch ==11016== ==11016== Conditional jump or move depends on uninitialised value(s) ==11016==at 0x400261C: _dl_start (in /lib/ld-2.7.so) ==11016==by 0x4016BE4: _start (in /lib/ld-2.7.so) ==11016== ==11016== Conditional jump or move depends on uninitialised value(s) ==11016==at 0x4002654: _dl_start (in /lib/ld-2.7.so) ==11016==by 0x4016BE4: _start (in /lib/ld-2.7.so) ==11016== ==11016== ERROR SUMMARY: 4 errors from 2 contexts (suppressed: 1 from 1) ==11016== malloc/free: in use at exit: 36,191,079 bytes in 183,114 blocks. ==11016== malloc/free: 1,932,467 allocs, 1,749,353 frees, 87,456,204 bytes allocated. ==11016== For counts of detected errors, rerun with: -v ==11016== searching for pointers to 183,114 not-freed blocks. ==11016== checked 43,651,904 bytes. ==11016== ==11016== LEAK SUMMARY: ==11016==definitely lost: 5,987 bytes in 253 blocks. ==11016== possibly lost: 6,744,305 bytes in 91,226 blocks. ==11016==still reachable: 29,440,787 bytes in 91,635 blocks. ==11016== suppressed:
Bug#461761: aptitude: segfaults when accessing options
On Mon, Mar 31, 2008 at 12:20:07PM +0200, Bram Senders wrote: To be sure that the patch what fixes it, I de-applied it and make again... but now aptitude still doesn't segfault! Hmm. It doesn't segfault anymore either with or without the patch. Maybe it's the build options? I try a straight debuild -- without your patch, and without any CXXFLAGS, and install that package, run it... no segfault on preferences! Install the exact same version (0.4.11-3) from the Debian archive... and it segfaults on preferences! Now I am very confused. Just to be sure, I tried building aptitude in a pbuilder enviroment, and the package built in there also does not segfault on preferences... I would almost suspect something goes wrong on Debian's build machine? Bram -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#461761: aptitude: segfaults when accessing options
On Mon, Mar 31, 2008 at 12:20:07PM +0200, Bram Senders [EMAIL PROTECTED] was heard to say: To be sure that the patch what fixes it, I de-applied it and make again... but now aptitude still doesn't segfault! Hmm. It doesn't segfault anymore either with or without the patch. Maybe it's the build options? I try a straight debuild -- without your patch, and without any CXXFLAGS, and install that package, run it... no segfault on preferences! Install the exact same version (0.4.11-3) from the Debian archive... and it segfaults on preferences! Now I am very confused. That's weird and disturbing. Unfortunately, I have no idea how the Debian package for powerpc was built, since it's compiled on an autobuilder. The only thing I can think of is that maybe it was built against an incompatible library: for instance, libsigc++-2.0 could have changed its ABI without upstream bumping the SONAME (easy to do by accident with C++ libraries). If this was the case, though, I'd expect aptitude to segfault all over, not just in the preferences screen. BTW: when you installed your hand-built package, you're sure you were running that and not some other version? i.e., if you ran make install to install aptitude systemwide, you'll need to remove it to get it out of $PATH. -rwxr-xr-x 1 bram bram 2287728 2008-03-31 11:48 aptitude-debuild-nopatch -rwxr-xr-x 1 bram bram 2807768 2008-03-31 11:48 aptitude-debian-archive , and a binary diff reveals that they are very different (that may not mean much, I don't know, I don't have experience with these things). aptitude-debuild-nopatch doesn't segfault on preferences, aptitude-debian-archive does. I have no real idea how to interpret a binary diff, but things like the build date and the exact version of each package in the build toolchain will have at least some impact on how the program is built. Does 0.4.11.1-1 segfault for you? Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#461761: aptitude: segfaults when accessing options
On Sat, 2008-03-29 at 19:50 -0700, Daniel Burrows wrote: On Sun, Mar 30, 2008 at 12:39:21AM +0100, Bram Senders [EMAIL PROTECTED] was heard to say: I am also on PowerPC (as is the original reporter), and I can reproduce this on my machine. What do you get if you install valgrind and run valgrind --log-file=/tmp/aptitude.grind aptitude , then reproduce the bug? Okay, here it is attached. Cheers, Bram ==5065== Memcheck, a memory error detector. ==5065== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al. ==5065== Using LibVEX rev 1804, a library for dynamic binary translation. ==5065== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP. ==5065== Using valgrind-3.3.0-Debian, a dynamic binary instrumentation framework. ==5065== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al. ==5065== For more details, rerun with: -v ==5065== ==5065== My PID = 5065, parent PID = 4248. Prog and args are: ==5065==aptitude ==5065== ==5065== Conditional jump or move depends on uninitialised value(s) ==5065==at 0x400261C: _dl_start (in /lib/ld-2.7.so) ==5065==by 0x4016BE4: _start (in /lib/ld-2.7.so) ==5065== ==5065== Conditional jump or move depends on uninitialised value(s) ==5065==at 0x4002654: _dl_start (in /lib/ld-2.7.so) ==5065==by 0x4016BE4: _start (in /lib/ld-2.7.so) ==5065== ==5065== Invalid read of size 1 ==5065==at 0xFFBBC7C: strlen (mc_replace_strmem.c:242) ==5065==by 0xF6593D4: __dcigettext (dcigettext.c:456) ==5065==by 0xF658290: dcgettext (dcgettext.c:53) ==5065==by 0x100F9F4C: add_menu(cwidget::widgets::menu_info*, std::string const, cwidget::util::ref_ptrcwidget::widgets::label const) (ui.cc:2385) ==5065==by 0x10118858: ui_init() (ui.cc:2520) ==5065==by 0x1001B2AC: main (main.cc:695) ==5065== Address 0x4037d5c is 12 bytes inside a block of size 72 free'd ==5065==at 0xFFB99BC: operator delete(void*) (vg_replace_malloc.c:342) ==5065==by 0xF961C80: std::string::_Rep::_M_destroy(std::allocatorchar const) (in /usr/lib/libstdc++.so.6.0.10) ==5065==by 0x10116F6C: __static_initialization_and_destruction_0(int, int) (basic_string.h:238) ==5065==by 0x10231CB4: (within /usr/bin/aptitude) ==5065==by 0x10019CC4: (within /usr/bin/aptitude) ==5065==by 0x10231934: __libc_csu_init (in /usr/bin/aptitude) ==5065==by 0xF6476B8: (below main) (libc-start.c:181) ==5065== ==5065== Invalid read of size 1 ==5065==at 0xFFBBC94: strlen (mc_replace_strmem.c:242) ==5065==by 0xF6593D4: __dcigettext (dcigettext.c:456) ==5065==by 0xF658290: dcgettext (dcgettext.c:53) ==5065==by 0x100F9F4C: add_menu(cwidget::widgets::menu_info*, std::string const, cwidget::util::ref_ptrcwidget::widgets::label const) (ui.cc:2385) ==5065==by 0x10118858: ui_init() (ui.cc:2520) ==5065==by 0x1001B2AC: main (main.cc:695) ==5065== Address 0x4037d5d is 13 bytes inside a block of size 72 free'd ==5065==at 0xFFB99BC: operator delete(void*) (vg_replace_malloc.c:342) ==5065==by 0xF961C80: std::string::_Rep::_M_destroy(std::allocatorchar const) (in /usr/lib/libstdc++.so.6.0.10) ==5065==by 0x10116F6C: __static_initialization_and_destruction_0(int, int) (basic_string.h:238) ==5065==by 0x10231CB4: (within /usr/bin/aptitude) ==5065==by 0x10019CC4: (within /usr/bin/aptitude) ==5065==by 0x10231934: __libc_csu_init (in /usr/bin/aptitude) ==5065==by 0xF6476B8: (below main) (libc-start.c:181) ==5065== ==5065== Invalid read of size 1 ==5065==at 0xFFBD790: memcpy (mc_replace_strmem.c:402) ==5065==by 0xF659408: __dcigettext (dcigettext.c:462) ==5065==by 0xF658290: dcgettext (dcgettext.c:53) ==5065==by 0x100F9F4C: add_menu(cwidget::widgets::menu_info*, std::string const, cwidget::util::ref_ptrcwidget::widgets::label const) (ui.cc:2385) ==5065==by 0x10118858: ui_init() (ui.cc:2520) ==5065==by 0x1001B2AC: main (main.cc:695) ==5065== Address 0x4037d97 is 71 bytes inside a block of size 72 free'd ==5065==at 0xFFB99BC: operator delete(void*) (vg_replace_malloc.c:342) ==5065==by 0xF961C80: std::string::_Rep::_M_destroy(std::allocatorchar const) (in /usr/lib/libstdc++.so.6.0.10) ==5065==by 0x10116F6C: __static_initialization_and_destruction_0(int, int) (basic_string.h:238) ==5065==by 0x10231CB4: (within /usr/bin/aptitude) ==5065==by 0x10019CC4: (within /usr/bin/aptitude) ==5065==by 0x10231934: __libc_csu_init (in /usr/bin/aptitude) ==5065==by 0xF6476B8: (below main) (libc-start.c:181) ==5065== ==5065== Invalid read of size 1 ==5065==at 0xFFBD7A0: memcpy (mc_replace_strmem.c:402) ==5065==by 0xF659408: __dcigettext (dcigettext.c:462) ==5065==by 0xF658290: dcgettext (dcgettext.c:53) ==5065==by 0x100F9F4C: add_menu(cwidget::widgets::menu_info*, std::string const, cwidget::util::ref_ptrcwidget::widgets::label const) (ui.cc:2385) ==5065==by 0x10118858: ui_init() (ui.cc:2520) ==5065==by 0x1001B2AC: main (main.cc:695) ==5065==
Bug#461761: aptitude: segfaults when accessing options
On Sun, Mar 30, 2008 at 01:46:47PM +0200, Bram Senders [EMAIL PROTECTED] was
heard to say:
On Sat, 2008-03-29 at 19:50 -0700, Daniel Burrows wrote:
On Sun, Mar 30, 2008 at 12:39:21AM +0100, Bram Senders [EMAIL PROTECTED]
was heard to say:
I am also on PowerPC (as is the original reporter), and I can reproduce
this on my machine.
What do you get if you install valgrind and run
valgrind --log-file=/tmp/aptitude.grind aptitude
, then reproduce the bug?
Okay, here it is attached.
Cheers,
Bram
==5065== Invalid read of size 1
==5065==at 0xFFBBC7C: strlen (mc_replace_strmem.c:242)
==5065==by 0xF6593D4: __dcigettext (dcigettext.c:456)
==5065==by 0xF658290: dcgettext (dcgettext.c:53)
==5065==by 0x100F9F4C: add_menu(cwidget::widgets::menu_info*, std::string
const, cwidget::util::ref_ptrcwidget::widgets::label const) (ui.cc:2385)
(...)
So, all this stuff in the menu code is due to a bug in ui.cc: it
stores a reference to a temporary string and then reads from it. The
attached patch fixes this, but I doubt it's the problem you're seeing:
reading from bad memory shouldn't cause corruption later on.
==5065== Invalid read of size 4
==5065==at 0xFDCA7EC: cwidget::widgets::widget::widget()
(limit_reference.h:81)
And we crash. The code at this point is just connecting some signals
to this as far as I can tell, and in fact the line of code that's
referenced above is just initializing a reference without even casting
it! That shouldn't crash unless this somehow became NULL, but the
address valgrind reports isn't NULL.
Can you compile the program with
CXXFLAGS=-g -O0 -fno-inline ./configure make
and valgrind the result?
Thanks,
Daniel
diff -r 7d1a4a4d43db -r c7a2375be38c src/ui.cc
--- a/src/ui.cc Sun Mar 30 14:24:28 2008 +0200
+++ b/src/ui.cc Sun Mar 30 09:29:37 2008 -0700
@@ -2372,7 +2372,7 @@ cw::menu_info help_menu_info[]={
sigc::ptr_fun(do_help_faq)),
cw::menu_info(cw::menu_info::MENU_ITEM, N_(^News), NULL,
- ssprintf(N_(View the important changes made in each version of %s), PACKAGE).c_str(),
+ N_(View the important changes made in each version of PACKAGE),
sigc::ptr_fun(do_help_news)),
cw::menu_info(cw::menu_info::MENU_ITEM, N_(^License), NULL,
Bug#461761: aptitude: segfaults when accessing options
Hi there,
I am also on PowerPC (as is the original reporter), and I can reproduce
this on my machine.
GDB output follow:
=== 8 ===
(gdb) bt full
#0 widget (this=0x1071bb18, __vtt_parm=value optimized out)
at /usr/include/sigc++-2.0/sigc++/limit_reference.h:81
No locals.
#1 0x0fde6dd4 in passthrough (this=value optimized out,
__vtt_parm=0x102388d0) at container.h:35
No locals.
#2 0x0fdfa6c0 in table (this=value optimized out,
__vtt_parm=0x102388cc)
at table.cc:60
No locals.
#3 0x100361cc in apt_options_view (this=0x1071bb18) at
apt_options.cc:514
No locals.
#4 0x100372e0 in aptitude::ui::config::make_options_tree ()
at apt_options.cc:577
No locals.
#5 0x1010ec5c in do_show_options_tree () at ui.cc:689
w = {ref = 0x102f91b0}
#6 0x1001ede8 in sigc::adaptor_functorsigc::pointer_functor0void
::operator() (this=value optimized out)
at /usr/include/sigc++-2.0/sigc++/functors/ptr_fun.h:77
No locals.
#7 0x1001ee14 in
sigc::internal::slot_call0sigc::pointer_functor0void, void::call_it
(rep=value optimized out)
at /usr/include/sigc++-2.0/sigc++/functors/slot.h:103
---Type return to continue, or q return to quit---
No locals.
#8 0x0fdc7e18 in cwidget::widgets::menu::handle_key (this=0x102fa350,
k=value optimized out) at /usr/include/sigc++-2.0/sigc
++/signal.h:548
selected = 0
#9 0x0fe10ff4 in cwidget::widgets::widget::dispatch_key
(this=0x102fa350,
[EMAIL PROTECTED]) at widget.cc:267
rval = 80
#10 0x0fdd10c8 in cwidget::widgets::menubar::handle_key
(this=0x102f2510,
[EMAIL PROTECTED]) at menubar.cc:599
No locals.
#11 0x0fe10ff4 in cwidget::widgets::widget::dispatch_key
(this=0x102f2510,
[EMAIL PROTECTED]) at widget.cc:267
rval = 60
#12 0x0fd99d10 in
cwidget::toplevel::input_thread::get_input_event::dispatch (
this=0x1071b088) at toplevel.cc:399
ev = {id = -16459, x = 266687216, y = 0, z = 0, bstate =
266687168}
k = {ch = 13, function_key = false}
wch = 13
status = value optimized out
read_anything = false
last_read_error = value optimized out
#13 0x0fd93fc4 in cwidget::toplevel::mainloop (synch=value optimized
out)
at toplevel.cc:1124
---Type return to continue, or q return to quit---
ev = (class cwidget::toplevel::event *) 0x1071b088
main_level = 1
#14 0x100f8170 in ui_main () at ui.cc:2652
No locals.
#15 0x1001b628 in main (argc=value optimized out, argv=value
optimized out)
at main.cc:729
p = {ref = 0x10301558}
status_fname = 0x0
display_format = {static npos = 4294967295,
_M_dataplus = {std::allocatorchar =
{__gnu_cxx::new_allocatorchar = {No data fields}, No data
fields}, _M_p = 0x102c737c %c%a%M %p# - %d#}}
sort_policy = {static npos = 4294967295,
_M_dataplus = {std::allocatorchar =
{__gnu_cxx::new_allocatorchar = {No data fields}, No data
fields}, _M_p = 0x102c3494 name}}
width = {static npos = 4294967295,
_M_dataplus = {std::allocatorchar =
{__gnu_cxx::new_allocatorchar = {No data fields}, No data
fields}, _M_p = 0x102bd45c }}
simulate = false
download_only = false
arch_only = false
update_only = false
install_only = false
queue_only = false
---Type return to continue, or q return to quit---
assume_yes = false
fix_broken = false
safe_upgrade_no_new_installs = false
safe_resolver_no_new_installs = false
safe_resolver_no_new_upgrades = false
always_use_safe_resolver = false
safe_resolver_option = false
full_resolver_option = false
showvers = false
showdeps = false
showsize = false
visual_preview = false
always_prompt = false
verbose = 0
seen_quiet = false
quiet = 0
user_tags =
{std::_Vector_baseaptitude::cmdline::tag_application,std::allocatoraptitude::cmdline::tag_application
= {
_M_impl = {std::allocatoraptitude::cmdline::tag_application =
{__gnu_cxx::new_allocatoraptitude::cmdline::tag_application = {No
data fields}, No data fields}, _M_start = 0x0, _M_finish = 0x0,
_M_end_of_storage = 0x0}}, No data fields}
curopt = value optimized out
---Type return to continue, or q return to quit---
#16 0x0f690720 in ?? () from /lib/libc.so.6
No symbol table info available.
#17 0x0f6908e0 in __libc_start_main () from /lib/libc.so.6
No symbol table info available.
#18 0x in ?? ()
No symbol table info available.
=== 8 ===
Cheers,
Bram
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#461761: aptitude: segfaults when accessing options
On Sun, Mar 30, 2008 at 12:39:21AM +0100, Bram Senders [EMAIL PROTECTED] was heard to say: I am also on PowerPC (as is the original reporter), and I can reproduce this on my machine. What do you get if you install valgrind and run valgrind --log-file=/tmp/aptitude.grind aptitude , then reproduce the bug? Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#461761: aptitude: segfaults when accessing options
On Sun, Jan 20, 2008 at 05:02:55PM +0100, Joseph D. [EMAIL PROTECTED] was heard to say: --- Please enter the report below this line. --- I start aptitude as root without any option, press C-t to access the menu, go to options and press enter: segfault. What architecture are you running? If you install aptitude-dbg, can you run in gdb and get a backtrace? Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
