Apache OpenOffice (AOO) Bugzilla – Issue 27162
mksvconf crashes while determining parameters
Last modified: 2006-03-14 21:03:16 UTC
I get this while building OOo 1.1.1 on an Athlon Linux 2.6.4 system w/ glibc 2.3.2: ../../unxlngi4.pro/bin/mksvconf ../../unxlngi4.pro/inc/svconf.h char = signed char short = signed short int = signed int long = signed long sizeof(char) = 1 sizeof(short) = 2 sizeof(int) = 4 sizeof(long) = 4 sizeof(float) = 4 sizeof(double) = 8 sizeof(void *) = 4 LITTLEENDIAN (Intel, VAX, PowerPC) Stack waechst nach unten STACKALIGNMENT : 1 can not read address (nil) Segmentation fault dmake: Error code 139, while making '../../unxlngi4.pro/inc/svconf.h' It's crashing when char* p=NULL; InfoMemoryAccess(p); p = (char*)&p; InfoMemoryAccess(p); <------- CRASH InfoMemoryAccess() crashes in "CheckSetAccess(t_char, p)", CheckSetAccess() crashes in check(), which in turn crashes in result = func( eT, p ); despite the fact that signal(SIGSEGV, SignalHdl); was run and didn't indicate any errors (it doesn't even return SIG_ERR). SignalHdl() isn't being called. While this appears to be a bug in the kernel, the OOo build process seems to be the only thing in the world that triggers it, and there's an easy workaround: Add #define USE_FORK_TO_CHECK to tools/source/solar/solar.c
changing status to confirmed since reporter provided potentially valuable information concerning the most recent stable version of OOo.
Hi, Yes I can confirm this with all Linux kernel 2.6.X. For some reason sigsegv is not being caught anymore by the kernel when deliberately accessing address 0. I don't see any bug in our code but I have no looked closely. Changing this to use "fork" is indeed a good solution. I posted a similar patch to dev@tools.openoffice.org We should include this patch into OOo 1.1.2 and OOo 2.0 just to prevent problems. Kevin
looks rather like your area...
Hi, This was recently discussed on the Linux Kernel mailing list. The code in questions is incorrect as was explained to me by Ulrich Drepper. If we do not use sigsetjmp and siglonjmp then we leave the signal handler after the first signal is delivered with sigsegv blocked by the signal mask (this is done automatically upon entry to the signal handler). We then literally block the next segafult (which will not be caught) but this according to POSIX is undefined behavior (what happens when you block a sigsegv is not defined. So although this worked with pre-2.6, it no longer will and need not according to the spec. Please see this part of the thread for the testcase and the very clear explanation from Ulrich Drepper about what is going on: http://marc.theaimsgroup.com/?l=linux-kernel&m=108121235005834&w=2 http://marc.theaimsgroup.com/?l=linux-kernel&m=108121748330485&w=2 http://marc.theaimsgroup.com/?l=linux-kernel&m=108122077901489&w=2 http://marc.theaimsgroup.com/?l=linux-kernel&m=108122482322880&w=2 The solution for linux is easy: - use sigsetjmp and siglongjmp to properly save and resore the signal mask in the setjmp context so that sigsegv is never blocked preventing the undefined behavior. (I verified this on my machine) or - use fork and wait to detect what is segfaulting and what is not. Either solutions will work. We should target this fix for OOo 1.1.2 since it prevents builds on any linux 2.6 kernel based system. Kevin
Hi, I will try to set the target to 1.1.2 to prevent more problem reports. Kevin
Hi, Adding myself to CC on this to track its commit into the OOo 1.1.2 tree if possible. Kevin
missed to change the owner so my comment might have been missleading...
accepted
Hi, No actually I was responding to bero's original posting on the lkml and not specific to your changing ownership. Didn't mean to step on any toes, I just have run into the same problem since upgrading my kernel to 2.6 and I had already moved my build to use fork/wait here, but I was kind of curious as to what changed and why this didn't work. I assumed signal used to register a handler for sigsegv would first mask that signal before registering the handler and then unmask it. Similar to how you might do it with sigaction and sigprocmask and etc. But that is wrong. Kevin
fixed by using sigsetjmp/siglongjmp instead of setjmp/longjmp
set as verified
closing