On Friday 16 January 2009 19:39:19 Kevin Day wrote: > On Fri, Jan 16, 2009 at 5:02 AM, Carmelo AMOROSO <[email protected]> wrote: > > Kevin Day wrote: > >> This is more a less a fix of the symptom, the cause of why this memory > >> is assumed to be allocated and how is it not being allocated. > >> > >> The segfault: > >> ==31258== Process terminating with default action of signal 11 > >> (SIGSEGV): dumping core > >> ==31258== Access not within mapped region at address 0x0 > >> ==31258== at 0x40136C8: strlen (in > >> /toolchain/lib/valgrind/x86-linux/vgpreload_memcheck.so) > >> ==31258== by 0x403362F: _locale_set_l (locale.c:809) > >> ==31258== by 0x403388B: _locale_init_l (locale.c:932) > >> ==31258== by 0x40338B6: _locale_init (locale.c:941) > >> ==31258== by 0x40860E1: __uClibc_init (__uClibc_main.c:223) > >> ==31258== by 0x40040A9: _dl_get_ready_to_run (ldso.c:827) > >> ==31258== by 0x4001A42: ??? (dl-startup.c:311) > >> ==31258== by 0x4000AF8: _start (in /tools/lib/ld-uClibc-0.9.30.so) > >> > >> Which happens to be the lines: > >> for (c = 0 ; c < 10 ; c++) { > >> ((unsigned char *)d)[c] = strlen(x[c]); > >> assert(d[c] > 0); > >> } > >> > >> I am not sure whether it is than x is not being allocated or some x[c] > >> is not being allocated so I checked both cases: > >> if (x){ > >> for (c = 0 ; c < 10 && x[c]; c++) { > >> ((unsigned char *)d)[c] = strlen(x[c]); > >> assert(d[c] > 0); > >> } > >> } > >> > >> This seems to prevent the segfault. > >> But again, this is a fix for the symptom and not the cause. > > > > indeed the final effect of the patch is to hide a real, likely obscure, > > bug. So we should understand what is going wrong. > > I'm not familiar with valgrind tools. > > I think it should be better if you can create a simpler test case > > showing the problem. > > > > Cheers, > > carmelo > > It appears that the problem occurs when using the pre-generated > locale: uClibc-locale-030818.tgz. > That's about as much as I have been able to find out so far..
I've been fiddling with the locales recently, and meant to ask about this: According to extra/locale/README: > NOTE: While its possible to use this stuff for native != target arch, > you'll have to either write a converter to account for endianess and > struct padding issues, or run the mmap file generator on your target > arch. But all these programs will be rewritten at some point. I _think_ that the locale data hasn't got problems with word size, but it does seem to have problems with endianness and with struct padding. I may be able to reorder the structures so padding isn't an issue, and I can just write everything out little endian and use whatever the byteswap macros are. (if I can find 'em; Busybox has some in platform.h I could steal, but I'd rather use the existing ones if you have any...) I also don't have any test cases. I have a half-dozen test platforms (under qemu) but I never use locales so I dunno what I'm supposed to look for to tell whether or not this works... Rob _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
