Bug 3919 - crash in _longjmp_unwind (siglongjmp)
Summary: crash in _longjmp_unwind (siglongjmp)
Status: NEW
Alias: None
Product: uClibc
Classification: Unclassified
Component: Other (show other bugs)
Version: unspecified
Hardware: PC Linux
: P5 normal
Target Milestone: ---
Assignee: Bernhard Reutner-Fischer
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-06-25 09:30 UTC by busybox-bugzilla
Modified: 2011-06-26 08:09 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description busybox-bugzilla 2011-06-25 09:30:21 UTC
with current builds, siglongjmp always jumps to 0 and crashes in static builds without threads. reason is this test

  if (__pthread_cleanup_upto != NULL)

which is always true even, even if the function address is 0.

fixing it in a similar way as http://ue.tst.eu/9d0e9de564d5c343c524e9742a17d204.txt makes it work - i verified with this version of jmp-unwind.c (there might be other occurences of this bug):

/* Defeat compiler optimization which assumes function addresses are never NULL */
static int not_null_ptr(const void *p)
{
       const void *q;
       __asm__ (""
               : "=r" (q) /* output */
               : "0" (p) /* input */
       );
       return q != 0;
}

void _longjmp_unwind (jmp_buf env, int val);
void
_longjmp_unwind (jmp_buf env, int val)
{
#ifdef SHARED
  if (__libc_pthread_functions_init)
    PTHFCT_CALL (ptr___pthread_cleanup_upto, (env->__jmpbuf,
                                              CURRENT_STACK_FRAME));
#else
  if (not_null_ptr(__pthread_cleanup_upto))
    __pthread_cleanup_upto (env->__jmpbuf, CURRENT_STACK_FRAME);
#endif
}
Comment 1 busybox-bugzilla 2011-06-25 10:48:44 UTC
there are a myriad of other checks (exit crashes the same way by a direct call to 0x0). maybe the recently-applied patch for uClibc_main is wrong, too - GCC should not optimize away weak function checks.

maybe there is a problem with declaring weak functions, so gcc thinks the symbols are not weak and thus assumes they are always nonzero?
Comment 2 busybox-bugzilla 2011-06-25 12:18:08 UTC
seems compiling with -fPIC causes gcc to optimise all checks for weak symbols out as true - I have etsted with 4.2, 4,4, 4.5 and 4.6.
Comment 3 busybox-bugzilla 2011-06-25 17:17:42 UTC
Seems this is a manifestation of http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32219 and thus, possibly a gcc bug that is still in 4.6.

That would mena that the patch already in uclibc that uses the asm workaround might also be not needed (or ALL such uses need it).
Comment 4 busybox-bugzilla 2011-06-25 19:08:55 UTC
right - setting DOPIC to n in uclibc config fixes all segfault issues observed (during perl-configure alone, there were alone 17 segfaults and the resulting miniperl crashe don exit).

This also means that applying the patch in bug#1033 is "wrong", it indeed only fixes one occurance, and gcc should normally have special casing for weak symbols (which works on amd64, and on x86 with !pic).
Comment 5 Bernhard Reutner-Fischer 2011-06-26 08:06:58 UTC
Apparently I never sent a patch with an updated comment. Thanks for the reminder.