uClibc 0.9.30 segfault + fix

Carmelo AMOROSO carmelo.amoroso at st.com
Fri Jan 16 11:02:42 UTC 2009


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
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> uClibc mailing list
> uClibc at uclibc.org
> http://lists.busybox.net/mailman/listinfo/uclibc



More information about the uClibc mailing list