[Libreoffice] segfault in sc

[Markus Mohrhard]

Hello Julien,

2011/10/10 Julien Nabet <serval2412 at yahoo.fr>:
> Le 10/10/2011 21:56, Michael Meeks a écrit :
>>
>> Hi Julien,
>>
>> On Mon, 2011-10-10 at 20:01 +0200, Julien Nabet wrote:
>>>
>>> In fact, I used make debug=true for the test but it was useless since I
>>> compile the whole repo in debug (my autogen.lastrun includes these lines
>>> :
>>
>>        Nice :-) well that means we get wonderful debugging symbols with
>> string
>> dumping&  all.
>>
>>> I put a break on appinit.cxx:231 + break __cxa_throw, I pasted a first
>>> part here :
>>> http://pastebin.com/NAX6AUrJ
>>>
>>> then a second part here :
>>> http://pastebin.com/BBepMkcY
>>
>>        These are beautiful :-)
>>
>>> If you need more info with different break or something, don't hesitate
>>> to tell me.
>>
>>        It'd be really nice to try to step through the constructor with 'n'
>> 'n'
>> 'n' to see where it bombs out, if you can, or ...
>
> Here what I did :
> - cd sc
> - export GDBCPPUNITTRACE="gdb --args"
> - make -sr
> - break app.cxx:309
> - run
> - break __cxa_throw
> and here the result :
> http://pastebin.com/HgZWbgx1

You did all right, you are just suffering from this incrdibly complicated test.
You suffer now from the fact thata lot of things that would be an
error in a normal libreoffice start are by design in this unit test. I
still hope that either Michael or me can reproduce that with one of
our builds because it might be one of these hidden and annoying
mistakes I made by writing some parts.

At the moment I think that Michael's point with setUp/tearDown is
perhaps the real problem. The 0x6 for the pointer in your valgrind
output looks a bit like a destructed object which pointer is later
reused. But well it would not be the first time that I'm searching in
this test for an error that is only a lifetime problem or a missing
line.

Feel free to play a bit with the unit test. I'm going to look if I can
reproduce it at my laptop(after the conference I have time for aVM
test) otherwise I'll disable the test for the conference time so that
as long as nobody has time to fix it, it does not break the build just
for a mistake in our test design.

Thanks again for your great help here.

Regards,
Markus