| Summary: | [PATCH] ldd segfault fix | ||
|---|---|---|---|
| Product: | uClibc | Reporter: | Natanael Copa <ncopa> |
| Component: | Shared Library Support | Assignee: | Carmelo Amoroso <carmelo.amoroso> |
| Status: | RESOLVED FIXED | ||
| Severity: | minor | CC: | uclibc-cvs |
| Priority: | P5 | ||
| Version: | 0.9.30.3 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Host: | x86 | Target: | x86 |
| Build: | |||
| Attachments: | 0001-ldd-segfault-fix.patch | ||
Hi Natanael, I'll give a try on my box too and let you know. Thanks for the patch. Hi Natanael, I'll give a try on my box too and let you know. Thanks for the patch. I gave a try on some of our boards and can confirm the issue. Applying the patch does seem to solve it. Hi Natanael, see my comments inline... diff --git a/utils/ldd.c b/utils/ldd.c index 1f1dc25..2cd173c 100644 --- a/utils/ldd.c +++ b/utils/ldd.c @@ -576,18 +576,20 @@ static struct library *find_elf_interpreter(ElfW(Ehdr) *ehdr) } newlib->name = NULL; newlib->path = NULL; - return NULL; + break; >>> I understand the change above ... } } - if (newlib == NULL) + if (newlib == NULL) { newlib = malloc(sizeof(struct library)); + if (newlib) + newlib->next = NULL; + } >>> why this one ? why do you need to initialise the next field... >>> if !newlib, we returns NULL anyway, so does it matter to set next ? >>> is this change actually required to fix the segfault you have seen ? >>> it seems not if (!newlib) return NULL; newlib->name = malloc(strlen(s) + 1); strcpy(newlib->name, s); newlib->path = strdup(newlib->name); newlib->resolved = 1; - newlib->next = NULL; (In reply to comment #4) > } > } > - if (newlib == NULL) > + if (newlib == NULL) { > newlib = malloc(sizeof(struct library)); > + if (newlib) > + newlib->next = NULL; > + } > > >>> why this one ? why do you need to initialise the next field... > >>> if !newlib, we returns NULL anyway, so does it matter to set next ? > >>> is this change actually required to fix the segfault you have seen ? > >>> it seems not Good question. I don't remember. I think you are right. probably not needed. (In reply to comment #5) > (In reply to comment #4) > > > } > > } > > - if (newlib == NULL) > > + if (newlib == NULL) { > > newlib = malloc(sizeof(struct library)); > > + if (newlib) > > + newlib->next = NULL; > > + } > > > > >>> why this one ? why do you need to initialise the next field... > > >>> if !newlib, we returns NULL anyway, so does it matter to set next ? > > >>> is this change actually required to fix the segfault you have seen ? > > >>> it seems not > > Good question. I don't remember. I think you are right. probably not needed. :) I would apply the minimal required fix, do you agree ? (In reply to comment #6) > :) I would apply the minimal required fix, do you agree ? yes. (In reply to comment #7) > (In reply to comment #6) > > > :) I would apply the minimal required fix, do you agree ? > > yes. Fine, fixed on master in commit b2c4199f0fd53c009858e7ce27f932a4ac92bc60 Thanks |
Created attachment 1483 [details] 0001-ldd-segfault-fix.patch Testcase: extern void _dl_getenv(void); void foo(void) { printf("foo: %x\n", &_dl_getenv); } linked as -shared ldd will segfault. Happens on 0.9.30.x and on current nptl.