Source: dietlibc Version: 0.33~cvs20110918-3 Severity: important Hector Oron dixit:
> dietlibc (0.33~cvs20110918-4) unstable; urgency=low > . > * d/rules: disable tc523086.c test on ARM (segfaults on armhf) We’re talking about the following test programme: http://anonscm.debian.org/gitweb/?p=collab-maint/dietlibc.git;a=blob;f=debian/test/tc523086.c;h=d160eb1fa977b816d1880fbcea0bcd59bdc09890;hb=7e687dbd3ae266d0bd678aea1be273cd341b7dd6 Could you please try to find out exactly _why_ (or at least _where_) this segfaults, as I’m not in the possession of access to an armhf box – as far as I can see, the programme is valid C, and if this segfaults on armhf, dietlibc is as broken there as on hppa and should indeed FTBFS due to failing this test. (Please do also try whether this segfaults with eglibc.) Is the segfault in strstr? Analysis: 13 if ((buf = malloc(32)) == NULL) 14 return (255); Let’s assume the malloc base is 0x1000. Then buf can be anything from 0x1000 to 0x101F (0x1020 would behave the same as 0x1000). 15 /* align */ 16 s = (void *)((((ptrdiff_t)buf + 15) & ~15) + 12); This assigns s a value of (depending on buf): 0x1000 → 0x100C (buf from 0x1000 to 0x101F) → 0x13 bytes available 0x1001 → 0x101C (buf from 0x1001 to 0x1020) → 0x04 bytes available 0x1010 → 0x101C (buf from 0x1010 to 0x102F) → 0x13 bytes available 0x101E → 0x102C (buf from 0x101E to 0x103D) → 0x11 bytes available 0x101F → 0x102C (buf from 0x101F to 0x103E) → 0x12 bytes available 17 s[0] = 'a'; 18 s[1] = '\0'; This writes to *s and *(s+1); as the minimum available is 4 bytes, this will be fine. 19 20 cp = strstr(Heuhaufen, s); Heuhaufen is a constant string, so the only variable here is s, which consists of the string "a" (NUL-terminated, 2 bytes long). I fail to see where this can segfault, other than in the dietlibc code (in which case the package RIGHTFULLY FTBFS), or in compiler- generated code (unlikely). Therefore I am raising Severity. bye, //mirabilos -- Solange man keine schmutzigen Tricks macht, und ich meine *wirklich* schmutzige Tricks, wie bei einer doppelt verketteten Liste beide Pointer XORen und in nur einem Word speichern, funktioniert Boehm ganz hervorragend. -- Andreas Bogk über boehm-gc in d.a.s.r -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
