Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#6006 closed Bug (fixed)

segfault against libuClibc-0.9.27.so on some tests when running 'make check'

Reported by: tals Owned by: mike.dld
Priority: Normal Milestone: 2.90
Component: libtransmission Version: 2.84+
Severity: Normal Keywords:
Cc:

Description

linux-2.4.28
uClibc-0.9.27
gcc-3.3.6
transmission-2.84+ (build from scratch)

'make check'

AR: segfault (see attachments)

Attachments (5)

test_failed.png (13.3 KB) - added by tals 6 years ago.
failed_tests
dmesg.png (30.9 KB) - added by tals 6 years ago.
dmesg
locale.h (8.5 KB) - added by tals 6 years ago.
6006-disable-uselocale-on-uclibc-below-0.9.34.patch (2.0 KB) - added by mike.dld 6 years ago.
tests_PASS.png (71.0 KB) - added by tals 6 years ago.

Download all attachments as: .zip

Change History (30)

Changed 6 years ago by tals

failed_tests

Changed 6 years ago by tals

dmesg

comment:1 Changed 6 years ago by mike.dld

Do you have a debugger there to see the backtraces?

comment:2 Changed 6 years ago by tals

The only GDB version I could build in my ENV. is gdb-5.3. Hope it helps. Similar behaviour with all failed tests:

(gdb) run
Starting program: /sources/transmission-2.84+/libtransmission/makemeta-test 
[New Thread 1024 (LWP 6638)]
[New Thread 2049 (LWP 6639)]
[New Thread 1026 (LWP 6640)]
[New Thread 2050 (LWP 6641)]
[New Thread 3074 (LWP 6642)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 3074 (LWP 6642)]
0xf74cc31c in free () from /lib/libc.so.0

comment:3 Changed 6 years ago by tals

(gdb) backtrace
#0  0xf74d635c in free () from /lib/libc.so.0
#1  0xf74ba4be in _locale_set_l () from /lib/libc.so.0
#2  0xf74ba9f6 in _locale_init_l () from /lib/libc.so.0
#3  0xf74baeba in newlocale () from /lib/libc.so.0
#4  0x0806b099 in use_numeric_locale (context=0xff7ffc28, locale_name=0x80c462b "C") at variant.c:70
#5  0x0806ce2d in tr_variantToBuf (v=0xff7ffca8, fmt=TR_VARIANT_FMT_BENC) at variant.c:1171
#6  0x0806cf71 in tr_variantToFile (v=0xff7ffca8, fmt=TR_VARIANT_FMT_BENC, filename=0x81771b0 "/sources/transmission-2.84+/libtransmission/sandbox-V60ZA9/folder.O5g9zw.torrent")
    at variant.c:1231
#7  0x08050118 in tr_realMakeMetaInfo (builder=0x81767e8) at makemeta.c:456
#8  0x0805020a in makeMetaWorkerFunc (unused=0x0) at makemeta.c:514
#9  0x08051a1f in ThreadFunc (_t=0x8177208) at platform.c:104
#10 0xf752f94b in pthread_start_thread () from /lib/libpthread.so.0
#11 0xf752f985 in pthread_start_thread_event () from /lib/libpthread.so.0

comment:4 Changed 6 years ago by mike.dld

Hmm, does this simple program crash as well?

#include <locale.h>

int main ()
{
    newlocale (LC_NUMERIC_MASK, "C", NULL);
    return 0;
}

Changed 6 years ago by tals

comment:5 Changed 6 years ago by tals

i386-linux-uclibc-gcc -g simple_prog.c
simple_prog.c: In function `main':
simple_prog.c:5: error: `LC_NUMERIC_MASK' undeclared (first use in this function)
simple_prog.c:5: error: (Each undeclared identifier is reported only once
simple_prog.c:5: error: for each function it appears in.)

I've also attached my 'locale.h'. If I'm not mistaken, a busybox env. doesn't provide full locale support.

comment:6 Changed 6 years ago by mike.dld

Oh, sorry, try compiling with -D_GNU_SOURCE or add #define _GNU_SOURCE before including locale.h.

Reading the file from uClibc, there's a nice comment:

   ...
   Attention: all these functions are *not* standardized in any form.
   This is a proof-of-concept implementation.  */

I wonder how well-tested this proof-of-concept is...

comment:7 Changed 6 years ago by tals

i386-linux-uclibc-gcc -g simple_prog.c -o simple_prog

...

(gdb) run
Starting program: /sources/simple_prog 

Program exited normally.

comment:8 Changed 6 years ago by mike.dld

Let's try this:

#define _GNU_SOURCE
#include <locale.h>
#include <stdio.h>

int main ()
{
    int i;

    for (i = 0; i < 100000; ++i)
    {
     	locale_t newloc, oldloc;

        newloc = newlocale (LC_NUMERIC_MASK, "C", NULL);
        if (newloc == 0)
          perror ("newlocale");
        oldloc = uselocale (newloc);
        if (oldloc == 0)
          perror ("uselocale(new)");
        if (uselocale (oldloc) == 0)
          perror ("uselocale(old)");
        freelocale (newloc);
    }

    return 0;
}

comment:9 Changed 6 years ago by tals

i386-linux-uclibc-gcc -g simple_prog_advanced.c -o simple_prog_advanced

...

(gdb) run
Starting program: /sources/simple_prog_advanced 

Program exited normally.
(gdb)

comment:10 Changed 6 years ago by mike.dld

And another one:

#define _GNU_SOURCE
#include <locale.h>
#include <stdio.h>
#include <pthread.h>

void * thread_func (void * arg)
{
    int i;

    for (i = 0; i < 10000; ++i)
    {
       	locale_t newloc, oldloc;

       	newloc = newlocale (LC_NUMERIC_MASK, "C", NULL);
       	if (newloc == 0)
          perror ("newlocale");
       	oldloc = uselocale (newloc);
       	if (oldloc == 0)
          perror ("uselocale(new)");
       	if (uselocale (oldloc) == 0)
          perror ("uselocale(old)");
       	freelocale (newloc);
    }

    return NULL;
}

int main ()
{
    int i;

    for (i = 0; i < 50; ++i)
      {
       	pthread_t thr;

       	pthread_create (&thr, NULL, &thread_func, NULL);
       	pthread_join (thr, NULL);
      }

    return 0;
}

Compile with -pthread (or -lpthread).

comment:11 Changed 6 years ago by tals

i386-linux-uclibc-gcc -g -lpthread simple_prog_3.c -o simple_prog_3

...

(gdb) run
Starting program: /sources/simple_prog_3 
[New Thread 1024 (LWP 10048)]

Program exited normally.
(gdb)

comment:12 Changed 6 years ago by mike.dld

Hmm... :)

comment:13 Changed 6 years ago by mike.dld

Judging by commit message, looks related: http://git.uclibc.org/uClibc/commit/?id=3902d0c47212193778225e5f5e8257f5584f3061

The change I believe is for uClibc 0.9.33.2, but relevant code piece is there in 0.9.27 as well.

Will you be able to apply the patch and rebuild uClibc to check if that's the issue?

Last edited 6 years ago by mike.dld (previous) (diff)

comment:14 Changed 6 years ago by mike.dld

Also, try running those test programs above without GDB, maybe that'll lead to crashes...

comment:15 Changed 6 years ago by mike.dld

  • Owner changed from jordan to mike.dld
  • Status changed from new to assigned

comment:16 follow-up: Changed 6 years ago by cfpp2p

I hope tals can compile patched 0.9.27. But that kind of fix might not suffice for some embedded devices:
#3826

This bug is present in 0.9.27 version. And 0.9.27 is very old version (released in Jan-2005). Upgrading is not possible, because root fs hardcoded in AzBox?'s ROM as CRAMFS. Reflashing of ROM is not a trivial operation.

Even so uClibc-0.9.33.2 is considered very outdated by some.

A fix involving transmission could allow such embedded devices to continue using transmission.

Might https://trac.transmissionbt.com/changeset/14533/trunk/libtransmission/variant.c be involved?

Last edited 6 years ago by cfpp2p (previous) (diff)

comment:17 in reply to: ↑ 16 Changed 6 years ago by mike.dld

Replying to cfpp2p:

A fix involving transmission could allow such embedded devices to continue using transmission.

Might https://trac.transmissionbt.com/changeset/14533/trunk/libtransmission/variant.c be involved?

This indeed is the commit that makes T crash now. I was thinking the same thing, to add some check for uClibc once tals confirms that the defect I found is indeed the one causing the crashes. Won't be the first uClibc-related fix (see #3826).

comment:18 Changed 6 years ago by mike.dld

Oh, just noticed that you linked to the very same ticket :)

comment:19 Changed 6 years ago by mike.dld

@tals, whether you will or will not be able to recompile uClibc, please test the patch provided to see if it helps as well. I'm checking for 0.9.34 as there's no way to check for that "extra version" ".2" bit.

Changed 6 years ago by tals

comment:20 follow-up: Changed 6 years ago by tals

Thanks for the patch provided! All tests passed successful (please see attachment).

I agree with cfpp2p - Reflashing of ROM is not a trivial operation and there is a very high risk of killing the device (can become a 'brick'). Root fs is read-only and hardcoded as 'squashfs' in my case.

/dev/rom0 on / type squashfs (ro)

Besides, uClibc libs delivered as already compiled in the
GPL:
http://fs.airlive.com/airlive_fileserver/uploads/GPL_Code/WMU-6500FS_GPL_R4.00b4_20080507_v1.tgz
toolchain:
http://fs.airlive.com/GPL_Code/GPL_toolChains_WMU-6000FS.zip

Which means, they should be re-compiled from scratch. I'll try and will leave a comment if successful.

comment:21 in reply to: ↑ 20 ; follow-up: Changed 6 years ago by mike.dld

Replying to tals:

Thanks for the patch provided! All tests passed successful (please see attachment).

Unfortunately, this'll potentially bring back crashes (#5851). But if you didn't see those before, not that big of a deal I guess.

comment:22 in reply to: ↑ 21 Changed 6 years ago by tals

Replying to mike.dld:

But if you didn't see those before, not that big of a deal I guess.

Well, the reason why I didn't see those before might be because I use Terminal or Web_Client only. In any case, if this patch is not included into 2.90 release I could use it just for me.

Thanks one more time.

Last edited 6 years ago by tals (previous) (diff)

comment:23 Changed 6 years ago by mike.dld

  • Milestone changed from None Set to 2.90
  • Resolution set to fixed
  • Status changed from assigned to closed

I had every intention of comitting this patch, just wanted to be sure that 0.9.34 (or rather 0.9.33.2) is indeed the version where crashes no longer occur. Since it's hard to test, let's hope for the better. It's there in r14577 now.

comment:24 Changed 6 years ago by tals

It looks like the commit was submitted for uClibc 0.9.33.2 - If to search the commit# in the Changelog:

http://git.uclibc.org/uClibc/commit/?id=3902d0c47212193778225e5f5e8257f5584f3061
http://www.uclibc.org/downloads/ChangeLog-0.9.33.1_0.9.33.2

comment:25 Changed 6 years ago by mike.dld

Sure it's 0.9.33.2, but as I noted before there is no way of checking for this version precisely in code. I can either check for 0.9.33 or 0.9.34, that's the most granularity one can get. Hence the check is made for 0.9.34, as 0.9.33 and 0.9.33.1 aren't fixed.

Note: See TracTickets for help on using tickets.