BusyBox Bug and Patch Tracking
BusyBox
  

Viewing Issue Simple Details Jump to Notes ] View Advanced ] Issue History ] Print ]
ID Category Severity Reproducibility Date Submitted Last Update
0005254 [uClibc] Architecture Specific major always 10-06-08 01:02 11-02-08 04:14
Reporter chrisz View Status public  
Assigned To uClibc
Priority normal Resolution fixed  
Status closed   Product Version 0.9.30
Summary 0005254: Can not build uClibc-0.9.30-rc1 on x86_64
Description I need to build uClibc on an x86_64 system including pthreads and locale support.

There are 2 issues. The first I can work around, the second I am having difficulty with.

Issue 0000001 is the same issue as reported in bug# 000254 without a resolution. The problem apparently occurs because at line 347 of stdlib.c, we have extern __typeof(strtol) __XL_NPP(strtoll);

Unfortunately, strtol is declared to return a long int, whereas strtoll_l is declared in stdlib.h to return a long long int, and thus we get a conflict. This also occurs 4 other times in this file on different functions. Simply commenting out these offending prototypes in stdlib.c allows the compilation to complete.

Issue 2 is the one I need assistance with. After completing the build, I compile and link it against bash. When I try and run, I get the following:

root:/sources/embedded/chris/bash/bash-3.2# chroot /mnt/clfs /bin/bash --login +h
argc=3 argv=0x7fffdd822478 envp=0x7fffdd822498
ELF header=0x7f23d5612000
First Dynamic section entry=0x7f23d5821de8
Scanning DYNAMIC section
Done scanning DYNAMIC section
About to do library loader relocations
Done relocating ldso; we can now use globals and make function calls!
_dl_get_ready_to_run:172: Cool, ldso survived making function calls
_dl_malloc:921: mmapping more memory
_dl_get_ready_to_run:354: Lib Loader: (0xd5612000) /lib/ld64-uClibc.so.0
_dl_get_ready_to_run:292: calling mprotect on the application program
_dl_get_ready_to_run:621: Loading: (0x7f23d540d000) /lib/libdl.so.0
_dl_get_ready_to_run:621: Loading: (0x7f23d513b000) /lib/libc.so.0
_dl_get_ready_to_run:621: Loading: (0x7f23d513b000) /lib/libc.so.0
_dl_get_ready_to_run:748: Beginning relocation fixups
transfering control to application @ 0x4180b0
/bin/bash: libc/stdio/_stdio.c: 283: _stdio_validate_FILE: Assertion `((unsigned int)(stream->__user_locking)) <= 2' failed.
Aborted

I'm stuck here and can't proceed further. Can anyone suggest what is happening and how to resolve it? At the point it is failing printf is not available (it causes a segfault if I try and use it) so I can't even insert debugging code to try and track down what is happening. I'm not sure if my short cut to solving issue 0000001 could be causing an unexpected problem here.

Looking for any assistance you can offer. Config is attached.

Thanks,

Chris
Additional Information
Attached Files  .config [^] (5,163 bytes) 10-06-08 01:02

- Relationships

- Notes
(0012864)
chrisz
10-06-08 08:29

An update on this issue.

I have traced the offending assertion back to at least as far as the function call vsnprintf. Now, there is a define statement in there that says:

#if defined(__USE_OLD_VFPRINTF__) && defined(__UCLIBC_HAS_THREADS__)
        f.__user_locking = 1; /* Set user locking. */
        __stdio_init_mutex(&f.__lock);
#endif

Now, my configuration can not use OLD_VFPRINTF because I need wchar, and USE_OLD_VPRINTF specifically depends on !wchar.

However, there is no corresponding mutex initialization done in the instance that wchar is used, at least in vsnprintf.

Question:

Should there be a mutex initialization in this function, or does the wchar model demand that it be done elsewhere? It appears that what is reaching stdio_validate_FILE in the __user_locking field is in fact, unitialized garbage.

Can someone who has worked on the code give me some advice on how to proceed from here?

Thanks for any assistance,

Chris
 
(0012874)
chrisz
10-06-08 08:36

Further note:

By changing line 49 in libc/stdio/vsnprintf.c from:

#if defined(__USE_OLD_VFPRINTF__) && defined(__UCLIBC_HAS_THREADS__)

to

#if defined(__UCLIBC_HAS_THREADS__)

My chroot and bash now work. Did I break anything else with this fix? Any opinions?

Chris
 
(0012884)
carmelo73
10-06-08 08:55

Hi,
I think the proper fix should be
#if (defined(__STDIO_BUFFERS) || defined(__USE_OLD_VFPRINTF__)) && defined(__UCLIBC_HAS_THREADS__)

as in ./libc/stdio/vdprintf.c

Interestingly I've never seen this problem, even if wchar is enabled for me.
 
(0013044)
bernhardf
10-08-08 02:15

You mention "bug# 000254" but that was a report to update zlib in buildroot?
 
(0013054)
bernhardf
10-08-08 02:18

Let's track the strtol issue in 0002544
 
(0014834)
rhabarber1848
11-02-08 03:51
edited on: 11-02-08 03:52

During my efforts to solve bug 5694 I came across the same problem mentioned here.

/sbin/init: libc/stdio/_stdio.c: 283: _stdio_validate_FILE: Assertion `((unsigned int)(stream->__user_locking)) <= 2' failed.

Environment:
Linux kernel 2.4.36.6, arch ppc
gcc 3.4.6
uClibc SVN rev. 22456 (I know its an old one)

To solve bug 5694 I need to know the first revision causing that bug, during
this I found this bug. It was solved by applying the patch from SVN rev 23367
plus the patch in note 0012884 from this bug report.

In uClibc .config these options are enabled:
UCLIBC_HAS_WCHAR=y
UCLIBC_HAS_LOCALE=y
UCLIBC_HAS_XLOCALE=y
DOASSERTS=y (patch from rev 23367 solved bug with this option enabled)

 
(0014844)
bernhardf
11-02-08 04:14

Fixed in r23901; Thanks, Carmelo
 

- Issue History
Date Modified Username Field Change
10-06-08 01:02 chrisz New Issue
10-06-08 01:02 chrisz Status new => assigned
10-06-08 01:02 chrisz Assigned To  => uClibc
10-06-08 01:02 chrisz File Added: .config
10-06-08 08:29 chrisz Note Added: 0012864
10-06-08 08:36 chrisz Note Added: 0012874
10-06-08 08:55 carmelo73 Note Added: 0012884
10-08-08 02:15 bernhardf Note Added: 0013044
10-08-08 02:18 bernhardf Note Added: 0013054
11-02-08 03:51 rhabarber1848 Note Added: 0014834
11-02-08 03:52 rhabarber1848 Issue Monitored: rhabarber1848
11-02-08 03:52 rhabarber1848 Note Edited: 0014834
11-02-08 04:14 bernhardf Status assigned => closed
11-02-08 04:14 bernhardf Note Added: 0014844
11-02-08 04:14 bernhardf Resolution open => fixed
11-02-08 04:14 bernhardf Fixed in Version  => 0.9.30


Copyright © 2000 - 2006 Mantis Group
Powered by Mantis Bugtracker