[Monotone-devel] Re: 0.37 dumps on my FreeBSD-6-stable amd64

[Lapo Luchini]

Lapo Luchini wrote:
> Lapo Luchini wrote:
>> % mtn --version
>> monotone 0.37 (revisione base: c21eefc002b8f9c430e9f4cc16c4af7b852f54ec)
> 
> The release dumps (also on "mtn st" on pretty much every workspace I
> have) and a "manual compile" of the same revision does not! -_-

OK, got it: the ports are compiled with -O2, while my "manual compile"
was "-ggdb -O0".
I tried to manually compile with "-ggdbc -O2" and got the same signal 11
dump, plus a nice backtrace from gdb:

Program terminated with signal 11, Segmentation fault.
(gdb) bt
#0  roster_t::do_deep_copy_from (this=0x7fffffffdd10, address@hidden)
at shared_ptr.hpp:179
#1  0x000000000061771d in roster_t::operator= (this=0x7fffffffdd10,
address@hidden) at roster.cc:310
#2  0x0000000000555b4d in database::get_roster (this=0x0, address@hidden,
address@hidden, address@hidden) at shared_ptr.hpp:308
#3  0x0000000000609cd7 in (anonymous
namespace)::make_roster_for_nonmerge (address@hidden, address@hidden,
address@hidden,
    address@hidden, address@hidden,
address@hidden) at roster.cc:1923
#4  0x000000000062ab2c in make_roster_for_revision (address@hidden,
address@hidden, address@hidden,
    address@hidden, address@hidden,
address@hidden) at roster.cc:1983
#5  0x0000000000506e82 in workspace::get_current_roster_shape
(this=0x7fffffffe0f0, address@hidden, address@hidden) at
work.cc:179
#6  0x00000000004ccdbb in commands::cmd_status::exec (this=0x0,
address@hidden, address@hidden, address@hidden) at
cmd_ws_commit.cc:502
#7  0x000000000046156f in commands::process (address@hidden,
address@hidden, address@hidden) at commands.cc:772
#8  0x00000000006d93ee in cpp_main (argc=11683904, argv=0xac0718) at
monotone.cc:271
#9  0x00000000006d9d35 in main (argc=2, argv=0x7fffffffe688) at
unix/main.cc:150
(gdb) list shared_ptr.hpp:179
174     //  except that Borland C++ has a bug, and g++ with -Wsynth warns
175     #if defined(__BORLANDC__) || defined(__GNUC__)
176
177         shared_ptr & operator=(shared_ptr const & r) // never throws
178         {
179             px = r.px;
180             pn = r.pn; // shared_count::op= doesn't throw
181             return *this;
182         }
183
(gdb) list roster.cc:310
305     roster_t &
306     roster_t::operator=(roster_t const & other)
307     {
308       root_dir.reset();
309       nodes.clear();
310       do_deep_copy_from(other);
311       return *this;
312     }
313
314

...and I have no clue how a variable assignement could dump a program,
and only with -O2 with that regard.
Anyone has an idea? (Zack?)
Should I simply accept it as a fact and force a lower optimization level
in FreeBSD's amd64 monotone port?

    Lapo