Apache OpenOffice (AOO) Bugzilla – Issue 49665
quit testtool gives a systematic segfault m105 Linux PPC
Last modified: 2008-05-16 03:27:45 UTC
Linux PPC / gcc-3.3 OOo1.9.105 + j2re/sdk IBM 142 Note : I have used porting component, but QA could be better ? Quit testools.bin gives a systematic segfault. Not sure this issue is really one, because the problem might be caused by missing ID for automated QA tests ( <http://www.openoffice.org/issues/show_bug.cgi?id=48615> ) Just the log, using gdb : Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 31388)] 0x10035db0 in TestToolObj::~TestToolObj () (gdb) where #0 0x10035db0 in TestToolObj::~TestToolObj () #1 0x1003606c in TestToolObj::~TestToolObj () #2 0x1003606c in TestToolObj::~TestToolObj () #3 0x1003606c in TestToolObj::~TestToolObj () #4 0x1003606c in TestToolObj::~TestToolObj () #5 0x1003606c in TestToolObj::~TestToolObj () #6 0x1003606c in TestToolObj::~TestToolObj () #7 0x1003606c in TestToolObj::~TestToolObj () #8 0x1003606c in TestToolObj::~TestToolObj () #9 0x1003606c in TestToolObj::~TestToolObj () #10 0x1003606c in TestToolObj::~TestToolObj () #11 0x1003606c in TestToolObj::~TestToolObj () #12 0x1003606c in TestToolObj::~TestToolObj () #13 0x1003606c in TestToolObj::~TestToolObj () #14 0x1003606c in TestToolObj::~TestToolObj () #15 0x1003606c in TestToolObj::~TestToolObj () #16 0x1003606c in TestToolObj::~TestToolObj () #17 0x1003606c in TestToolObj::~TestToolObj () #18 0x1003606c in TestToolObj::~TestToolObj () #19 0x1003606c in TestToolObj::~TestToolObj () Previous frame inner to this frame (corrupt stack?) (gdb) quit The program is running. Exit anyway? (y or n) y eric@alube:~$
isn't this fixed by gslpatches (static initialization)?
Not only PPC, I get it also on Solaris Sparc. Precondition: A test has to run before. Only starting and quitting testtool doesn't suffer in my case. It has nothing to do with issue 48615 Setting Target and owner. @ericb: If you don't agree, I will open an other bug for it... @GH: you are able to reproduce, and have maybe an idea?
ericb -> tbo I agree :-) Because I have no idea of what happens, I just can follow in CC. I just can say the start of both spadmin and testtool were problematic until pl provided us gslpatches cws to fix this. static initialisation did'nt work correctly. Now, only testtool has a problem when quitting. Spadmin works fine. Last but not least, Linux PPC has not yet QA id (this is <http://www.openoffice.org/issues/show_bug.cgi?id=48615> TASK ) Could it be the cause of the segfault when quit ? Hope this can help
Hi ericb, can you supply a callstack with sourcecode information (file and linenr) Maybe you will have to use an unstripped binary from automation module.
ericb -> gh I have rebuild a non striped version of testtool. Here is the log : starting program: /usr/local/openoffice.org1.9.110/program/testtool [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 7716)] [New Thread 32769 (LWP 7735)] [New Thread 16386 (LWP 7736)] [New Thread 32771 (LWP 7737)] [New Thread 49156 (LWP 7745)] [Thread 49156 (LWP 7745) exited] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 7716)] 0x10063544 in _STL::_Rb_tree<String, _STL::pair<String const, String>, _STL::_Select1st<_STL::pair<String const, String> >, _STL::less<String>, _STL::allocator<_STL::pair<String const, String> > >::clear (this=0x130) at _tree.h:446 446 if (_M_node_count != 0) { Current language: auto; currently c++ (gdb) bt #0 0x10063544 in _STL::_Rb_tree<String, _STL::pair<String const, String>, _STL::_Select1st<_STL::pair<String const, String> >, _STL::less<String>, _STL::allocator<_STL::pair<String const, String> > >::clear ( this=0x130) at _tree.h:446 #1 0x1006333c in ~_Rb_tree (this=0x130) at _tree.h:341 #2 0x10060eb0 in ~map (this=0x130) at /home/eric/OpenOffice/automation/source/testtool/tcommuni.cxx:93 #3 0x1003afe0 in ~TestToolObj (this=0x106978f8) at /home/eric/OpenOffice/automation/source/testtool/objtest.cxx:836 #4 0x1005ec34 in virtual thunk to TestToolObj::~TestToolObj() () at testapp.hxx:114 #5 0x0ff0f9c4 in SvRefBase::QueryDelete () from /usr/local/openoffice.org1.9.110/program/libtl680lp.so #6 0x0ff0f9c4 in SvRefBase::QueryDelete () from /usr/local/openoffice.org1.9.110/program/libtl680lp.so #7 0x0ff0f9c4 in SvRefBase::QueryDelete () from /usr/local/openoffice.org1.9.110/program/libtl680lp.so #8 0x0ff0f9c4 in SvRefBase::QueryDelete () from /usr/local/openoffice.org1.9.110/program/libtl680lp.so #9 0x0ff0f9c4 in SvRefBase::QueryDelete () from /usr/local/openoffice.org1.9.110/program/libtl680lp.so #10 0x0ff0f9c4 in SvRefBase::QueryDelete () from /usr/local/openoffice.org1.9.110/program/libtl680lp.so #11 0x0ff0f9c4 in SvRefBase::QueryDelete () from /usr/local/openoffice.org1.9.110/program/libtl680lp.so #12 0x0ff0f9c4 in SvRefBase::QueryDelete () from /usr/local/openoffice.org1.9.110/program/libtl680lp.so #13 0x0ff0f9c4 in SvRefBase::QueryDelete () from /usr/local/openoffice.org1.9.110/program/libtl680lp.so #14 0x0ff0f9c4 in SvRefBase::QueryDelete () from /usr/local/openoffice.org1.9.110/program/libtl680lp.so #15 0x0ff0f9c4 in SvRefBase::QueryDelete () from /usr/local/openoffice.org1.9.110/program/libtl680lp.so #16 0x0ff0f9c4 in SvRefBase::QueryDelete () from /usr/local/openoffice.org1.9.110/program/libtl680lp.so #17 0x0ff0f9c4 in SvRefBase::QueryDelete () from /usr/local/openoffice.org1.9.110/program/libtl680lp.so #18 0x0ff0f9c4 in SvRefBase::QueryDelete () from /usr/local/openoffice.org1.9.110/program/libtl680lp.so #19 0x0ff0f9c4 in SvRefBase::QueryDelete () from /usr/local/openoffice.org1.9.110/program/libtl680lp.so ---Type <return> to continue, or q <return> to quit--- #20 0x0ff0f9c4 in SvRefBase::QueryDelete () from /usr/local/openoffice.org1.9.110/program/libtl680lp.so #21 0x0ff0f9c4 in SvRefBase::QueryDelete () from /usr/local/openoffice.org1.9.110/program/libtl680lp.so #22 0x0ff0f9c4 in SvRefBase::QueryDelete () from /usr/local/openoffice.org1.9.110/program/libtl680lp.so Previous frame inner to this frame (corrupt stack?) Of course, if you need other parts rebuild with debug=TRUE, simply ask me
.
ericb->gh Is this issue fixed ?
gh -> ericb yes but only in CWS gh13 for now
fixed in revision: 1.26.20.1 /cvs/util/automation/source/testtool/objtest.cxx
you want to verify?
ericb->gh Please excuse me, I completely forgot. I'll verify asap between christmas and new year. Is it correct for you ?
gh->ericb Perfect, tbo will hopefully verify the other tasks next week also.
ericb ->Gregor Hartmann FYI, I have checked gh13 and applied it against SRC680 m193, like expected in gh13 description. Build is now in progress on my Linux PPC box ( estimated buildtime ~15 hours), and I'll complete this issue asap.
Ok, run testtool.bin /. quit now does not cause a sefault anymore. We can start to use it on Linux PowerPC ( I'll probably do some tests ) Thank you very much for your work !! Issue verified fixed
you're wellcome, was a really spupid error of destroing objects in the wrong order and thanks for verifying!
*** Issue 73139 has been marked as a duplicate of this issue. ***
target dev tools
This Issue is 'Verified' and not updated in 1yr+, so Closing. A Closed Issue is a Happy Issue (TM). Regards, Andrew Cleaning-up and Closing old Issues as part of: ~ The Grand Bug Squash, pre v3 ~