| Anonymous | Login | Signup for a new account | 11-10-2008 12:56 PST |
| Main | My View | View Issues | Change Log | Docs |
| 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 |
|
||||||||
|
|
|||||||||
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 |
| Copyright © 2000 - 2006 Mantis Group |