[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#248352: seed48: segfaults, seems to expect nonstandard argument type



Package: libc6
Version: 2.3.2.ds1-12
Severity: critical
Tags: sid
Justification: breaks unrelated software

Hi

Attached you find a testcase, I stumbled over this when compiling
afbackup.

The gdb output that lead me to my conclusion that libc6 seems to expect
another argument type (and size ...) than seed48() normaly does:

(gdb) run
Starting program: /home/twoflower/arthur/doc/sp/afbackup/a.out 

Program received signal SIGSEGV, Segmentation fault.
__seed48_r (seed16v=0x94b0, buffer=0x40149f48) at seed48_r.c:33
33      seed48_r.c: No such file or directory.
        in seed48_r.c
(gdb) bt
#0  __seed48_r (seed16v=0x94b0, buffer=0x40149f48) at seed48_r.c:33
#1  0x400449c9 in seed48 (seed16v=0x40149f48) at seed48.c:27
#2  0x08048384 in main (argc=1, argv=0xbffff9e4) at seed48-testcase.c:7
(gdb) ptype buffer
type = struct drand48_data {
    short unsigned int __x[3];
    short unsigned int __old_x[3];
    short unsigned int __c;
    short unsigned int __init;
    long long unsigned int __a;
} *

As you see are the adresses of seed48's seed16v and __seed48_r's buffer the
same, so probably the unsigned short[3] that seed48 get's passed is being
casted to drand48_data (which is by far larger).

Sorry I can't help any more. I nonetheless hope this helps fixing some
of the breakage in other apps that seems to be taking place.

Thanks for your work!

ciao, 2ri

*** doc/sp/afbackup/seed48-testcase.c
#include <stdlib.h>

unsigned short seed[3] = {0x7d1b, 0xa934, 0xbf10};

int main(int argc, char** argv)
{
    seed48(seed);
}


-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (50, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.4
Locale: LANG=de_CH, LC_CTYPE=de_CH

Versions of packages libc6 depends on:
ii  libdb1-compat                 2.1.3-7    The Berkeley database routines [gl

-- no debconf information



Reply to: