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.
--
Kevin Day
uClibc-0.9.30-locale_fix-1.patch
Description: Binary data
_______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
