Apache OpenOffice (AOO) Bugzilla – Issue 40203
TestTool crashes under Mac OS X build
Last modified: 2007-01-03 06:02:58 UTC
[Computer:/opt/openoffice.org1.9.66/program] jogi% ./testtool.bin Bus error The Office application starts fine with Apple's X11. It is important to get this issue fixed that we can test the port with automated test bed.
./configure --with-x --with-lang=de en-US --with-jdk-home=/System/Library/Frameworks/ JavaVM.framework/Home --enable-fontconfig --with-system-freetype --enable-mozilla --with- system-libxml --with-system-python
Can you try this? cd /opt/openoffice.org1.9.66/program cp soffice testtool cd ../ program/testtool This worked in 645 for linux sparc but I havent tried 680 yet. Some priveleges may be needed to make this script. It makes a script needed to correctly call testtool.bin You also need chckout the qatesttool module to somewhere writeable, it holds the tests and the results. Also more information informtion here: http://qa.openoffice.org/qatesttool/index.html http://qa.openoffice.org/qatesttool/OOo_testtool.pdf Also a script to run all the tests together (very useful) http://qa.openoffice.org/source/browse/qa/qatesttool/script/unix/OOoTestRun_unix.sh
Added oooqa keyword. FWIW, sorry I should have reported this bug (assuming it is the same one) here long ago (I did report it on the QA and/or Porting list) - I have had TestTool crash very consistently with many versions of OOo for Mac OS X. I didn't make a lot of progress in debugging the problem, but I did have TestTool work reliably with certain versions of OOo for Mac OS X, and I couldn't figure out why the difference. One of my theories was a compiler optimization bug. I did build a version of TestTool with optimizations off, but I don't really know if that helped. Another theory had to do with tthe current network interface settings - use both Ethernet and dial-up modem, and my theory was the crash happened when the settings were dial-up modem (and I was not connected). I am not currently working on OOo 2.0, but right now trying to build OOo 1.1.4. Perhaps I can try TestTool again, and provide you with some of my crash logs and debugging info (from old crashes if necessary), and between the two of us, figure out what is the cause of the problem. I would love to be able run TestTool on OOo for Mac OS X and help out (I had Mac OS X specific changes in my test scripts before someone made similar changes to the scripts in CVS), but I gave up because of the problems. Perhaps you could post your crash log here, for comparison. Here is one of my old logs (on Mac OS X 10.2.x with XDarwin; but I believe I had also tried Mac OS X 10.3.x and Apple's X11.app without much success) : ********** Date/Time: 2004-10-02 19:57:20 -0700 OS Version: 10.2.6 (Build 6L60) Host: twinpeaks.local. Command: testtool.bin PID: 567 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00000384 Thread 0 Crashed: #0 0x00449498 in _ZN6ResMgr11GetResourceERK5ResIdPK8Resource (debugprint.cxx:68) #1 0x004478d0 in _ZN8Resource6GetResERK5ResId (debugprint.cxx:68) #2 0x0122a9a8 in _ZN11Accelerator11ImplLoadResERK5ResId #3 0x0122a978 in _ZN11AcceleratorC4ERK5ResId #4 0x00034bcc in _ZN8BasicApp4MainEv (tcommuni.cxx:232) #5 0x0117bcbc in _Z6SVMainv #6 0x012eb1e0 in main #7 0x000024e0 in _start (crt.c:267) #8 0x00002360 in start PPC Thread State: srr0: 0x00449498 srr1: 0x0200f930 vrsave: 0x00000000 xer: 0x00000000 lr: 0x00449424 ctr: 0x00447898 mq: 0x00000000 r0: 0x00002329 r1: 0xbffff170 r2: 0x00482c20 r3: 0x00000000 r4: 0x0000011a r5: 0xbffff370 r6: 0x00000010 r7: 0x00000028 r8: 0x00000068 r9: 0x00000400 r10: 0x00447974 r11: 0x0134c36c r12: 0x00447898 r13: 0x00000000 r14: 0x00000000 r15: 0x00000000 r16: 0x00000000 r17: 0x00000000 r18: 0x00000000 r19: 0x00000000 r20: 0x00000000 r21: 0x00000000 r22: 0x00000000 r23: 0xbffff370 r24: 0xbffff370 r25: 0x0000011a r26: 0x00002329 r27: 0x00000000 r28: 0x00000000 r29: 0x00000000 r30: 0xbffff410 r31: 0x00449424 Just a note to sparcmoz - I think the original OOoTestRun_unix.sh script was not appropriate for Mac OS X. I made my own run shell scripts, and I think I started to modify OOoTestRun_unix.sh, but probably didn't complete it.
I cannot run testtool.bin on linux sparc either at m68. The testtool script method described above that worked for 645 does not start the testtool application. Running testtool.bin gives a segfault and there is no stack trace because the stack is gone (0x00000).
reassign to gh.
Done but that does not fix the problem. And cp soffice to testtool should be obsolete since some versions. ./testtool: line 235: 620 Bus error "$sd_prog/$sd_binary" "$@"
Hi, I just confirm the bus error with m66, the only milestone I can completely build (with a lot of hacks). Sorry, I cannot give you the log, because I have updated since (m67 and now m70), working in python problem. Regards, eric bachard
concluding from the stack the ressourcefile stt680de.res (or whatever language you prefer) is missing or at least not in a path searched(should be ./res and . ) By the way the resolution of the sourcefile/line is at least for the following frame completely wrong #4 0x00034bcc in _ZN8BasicApp4MainEv (tcommuni.cxx:232) the code is in app.cxx:467
GH - just to be clear, the crash log I provided here is from OOo 1.1.x not OOo 1.9.x/2.0, and I'm not sure all your comments apply to OOo 1.1.x. Maybe I should write up a separate report for OOo 1.1.x.
terryt: The only thing which changed since 1.1.x is that the ressourcefiles now have ISO codes for the language. So for 1.1.x the name of the ressource would be stt64549.res (for german resources) The rest applies for both versions There should be a command named strace (or truss - depends on the unix family) whith which you can display the attempts to open files. Of corse the problem might also be a totally different one
got a stack with this version: src680m66 OS Version: 10.3.7 (Build 7S215) Report Version: 2 Command: testtool.bin Path: ./testtool.bin Version: ??? (???) PID: 1107 Thread: 0 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00000000 Thread 0 Crashed: 0 <<00000000>> 0xffff8660 __bzero + 0x60 1 libvcl680mxp.dylib 0x0146dd84 ImplInitSVData() + 0xc4 2 libvcl680mxp.dylib 0x0146a818 _ZN11ApplicationC4Ev + 0x30 3 testtool.bin 0x00058f00 0x1000 + 0x57f00 4 testtool.bin 0x0005dea0 0x1000 + 0x5cea0 5 dyld 0x8fe17990 call_module_initializers_for_objects + 0x1ac 6 dyld 0x8fe17458 call_module_initializers + 0x40 7 dyld 0x8fe14584 _dyld_make_delayed_module_initializer_calls + 0x6c 8 testtool.bin 0x00002940 0x1000 + 0x1940 9 testtool.bin 0x0000273c 0x1000 + 0x173c 10 dyld 0x8fe1a558 _dyld_start + 0x64
Created attachment 21423 [details] stack from Mac OSX system crashtool
Created attachment 21424 [details] ktrace on running testtool
Something vaguely similar on linux sparc? Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 2296)] 0x00000000 in ?? () (gdb) bt #0 0x00000000 in ?? () #1 0x716b8db8 in __libc_start_main () from /lib/libc.so.6 #2 0x000344a4 in _start () #3 0x000344a4 in _start () Previous frame identical to this frame (corrupt stack?) (gdb)
Created attachment 21425 [details] strace for linux sparc
The testtool.bin application starts OK in linux sparc with SRC680_m71s1, sorry i cannot say if it was fixed sooner.
I would apologize for perhaps complicating the discussion here, but I feel some improvements could be made to the documentation or code, and we wouldn't have the problem I described. I did some investigation with OOo 1.1.4 on Mac OS X, and your clue about the missing resources was helpful. From documentation I knew to copy the "program/soffice" script as "program/testtool", to copy "automation/unxmacxp.pro/bin/testtool" as "program/testtool.bin", and to make sure "program/ libsts645mxp.dylib" was copied from the solver, but there was no mention (that I can find) of making sure any necessary resources were present. I think I used to copy "automation/unxmacxp.pro/bin/ tma64501.res" as "program/tma64501.res" or "program/testtool.res" but this was probably wrong. I don't know how my previous successes with QATestTool on Mac OS X worked - apparently for OOo 1.1rc5 and OOo 1.1.1rc3 - because when I searched for "stt*.res" in those locations, none was found. Nonetheless if I omitted "stt64501.res" from its correct location in OOo 1.1.4, I did get a crash as previously described. Here is the most current crash log : Host Name: twinpeaks.local Date/Time: 2005-01-16 18:45:16 -0800 OS Version: 10.3.3 (Build 7F44) Report Version: 2 Command: testtool.bin Path: /Volumes/MoreApps/OOo_1.1.4/program/testtool.bin Version: ??? (???) PID: 434 Thread: 0 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00000384 Thread 0 Crashed: 0 libtl645mxp.dylib 0x0041349c ResMgr::GetResource(ResId const&, Resource const*) + 0x84 (debugprint.cxx:68) 1 libtl645mxp.dylib 0x004118d4 Resource::GetRes(ResId const&) + 0x38 (debugprint.cxx:68) 2 libvcl645mxp.dylib 0x019e9848 Accelerator::ImplLoadRes(ResId const&) + 0x1c 3 libvcl645mxp.dylib 0x019e9818 Accelerator::Accelerator[unified](ResId const&) + 0xb4 4 testtool.bin 0x0002c82c BasicApp::Main() + 0x478 5 libvcl645mxp.dylib 0x0193ab34 SVMain() + 0x58 6 libvcl645mxp.dylib 0x01aaa19c main + 0x38 7 testtool.bin 0x00001f14 _start + 0x17c (crt.c:267) 8 testtool.bin 0x00001d94 start + 0x30 PPC Thread State: srr0: 0x0041349c srr1: 0x0200f930 vrsave: 0x00000000 cr: 0x24000422 xer: 0x00000002 lr: 0x00413428 ctr: 0x0041189c r0: 0x00002329 r1: 0xbffff2f0 r2: 0x0044cc20 r3: 0x00000000 r4: 0x0000011a r5: 0xbffff4f0 r6: 0x00000010 r7: 0x00000000 r8: 0x022023b8 r9: 0x00000400 r10: 0x00411978 r11: 0x01b0b36c r12: 0x0041189c r13: 0x00000000 r14: 0x00000000 r15: 0x00000000 r16: 0x00000000 r17: 0x00000000 r18: 0x00000000 r19: 0x00000000 r20: 0x00000000 r21: 0x00000000 r22: 0x00000000 r23: 0xbffff4f0 r24: 0xbffff4f0 r25: 0x0000011a r26: 0x00002329 r27: 0x00000000 r28: 0x00000000 r29: 0x00000000 r30: 0xbffff590 r31: 0x00413428 In short, crashing (perhaps there is something wrong with the debugprint.cxx code) is a poor substitute for reporting a missing file. When I copied "stt64501.res" from the solver to "program/resource/stt64501.res", I was able to at least launch and run QATestTool. Maybe this resource file is installed as part of the installation process on other platforms, but it certainly isn't on Mac OS X, and I mentioned above, I don't see any reference to it in the documentation. I guess I should try to contribute improvements to the whole experience... Anyway, although I was able to launch and run QATestTool for OOo 1.1.4 on Mac OS X, when I tried running the "first.bas" script, it failed with an unknown symbol "get" in one of the included files. I haven't tried to track down this yet. Just for the benefit of other Mac OS X readers, "ktrace" is probably not what you want. If you are to use any tool for tracing what files QATestTool opens, use the "fs_usage" tool.
These are now 2 different issues; Would the person who complains about 1.1.4 please open a new bug? This bug is for the 2.0 release. Thank you.
Maybe this helps a little bit: issue 39914 is about adding main function to smooth gcc /cvs/util/automation/source/app/testbasi.cxx /cvs/util/automation/source/miniapp/testapp.cxx +#ifdef MACOSX +int main( int argc, char **argv ) +{ + return 0; +}
btw: it seems to be wrong to apply the main() patch *** This issue has been marked as a duplicate of 39927 ***
closing