help-libidn
[Top][All Lists]
Advanced

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

libidn-1.25: runaway validation test tst_pr29 on some systems


From: Nelson H. F. Beebe
Subject: libidn-1.25: runaway validation test tst_pr29 on some systems
Date: Thu, 24 May 2012 17:45:49 -0600 (MDT)

I've successfully built, validated, and installed libidn-1.25 on
most of the 25+ flavors of Unix in our test lab.

However, on these five

        Apple PowerMac G4 (2 500 MHz PowerPC 7400 CPUs, 256MB RAM);
        GNU/Linux 2.6.34-gentoo-r1 (Gentoo Base System version 1.12.13)

        Apple PowerMac G5 (4 2500 MHz PPC970MP CPUs, 8GB RAM);
        GNU/Linux 2.6.31-gentoo-r6 (Gentoo Base System release 1.12.13)

        DEC Alpha 4100-5/466 (4 21164 EV5 CPUs, 466 MHz, 2GB RAM);
        GNU/Linux 2.6.34-gentoo-r1 (Gentoo Base System release 1.12.13)

        SGI Origin/200-4 (180 MHz) (4 R10000 CPUs);
        IRIX 6.5

        Sun Blade 1500 (1062 MHz TI UltraSparc IIIi (Jalapeno), 1GB RAM);
        GNU/Linux 2.6.31-gentoo-r7 (Gentoo 2.0.3)

the tests proceed successfully for a while, but then go into an
infinite loop:

        ...
        PASS: tst_idna2
        PASS: tst_idna3
        PASS: tst_idna4
        PASS: tst_nfkc
        ... no further output ...

The output stops at the same line on each of the five systems.

If I run the top utility, I get something like this on each
system:

          PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  P COMMAND
         4963 beebe     20   0  3680  464  328 R 98.9  0.0 117:21.49 2 tst_pr29
         9027 beebe     24   4  3680  464  328 R 98.9  0.0 517:04.23 1 tst_pr29
        27695 beebe     24   4  3680  464  328 R 98.9  0.0 527:24.64 3 tst_pr29
         5264 beebe     20   0  3616 1832 1400 R  1.5  0.1   0:00.44 0 top

Four of the five loopers are big-endian, but the Alpha system is little-endian.

If I attach a debugger to a looping process, I find:

        % gdb -p 4963
        ...
        1206    pr29.c: No such file or directory.
        (gdb) where
        #0  in_last_column_row (row=<optimized out>, c=<optimized out>) at 
pr29.c:1206
        #1  pr29_4 (in=0x120002b30, len=3) at pr29.c:1260
        #2  0x0000000120000d6c in doit () at tst_pr29.c:120
        #3  0x0000000120001938 in main (argc=<optimized out>, argv=0x11fa14378) 
at utils.c:146
        
        % dbx  -p 17973423
        (dbx) where
        >  0 in_last_column_row(c = 18193, row = 12) 
["/export/home/0066/build-indigo-irix6/bare/libidn-1.19/lib/pr29.c":1206, 
0x5ffc93d4]
           1 pr29_4(in = 0x10014f18, len = 3) 
["/export/home/0066/build-indigo-irix6/bare/libidn-1.19/lib/pr29.c":1261, 
0x5ffc95b8]
           2 doit(0x5fff7850, 0x58, 0x1, 0x1, 0x3, 0xd4c2b36d, 0x0, 0x3) 
["/export/home/0066/build-indigo-irix6/cc/libidn-1.25/tests/tst_pr29.c":120, 
0x10001568]
           3 main(0x0, 0x7ffb7ed4, 0x1, 0x0, 0x3, 0xd4c2b36d, 0x0, 0x3) 
["/export/home/0066/build-indigo-irix6/cc/libidn-1.25/tests/utils.c":146, 
0x100022a8]
           4 __start() 
["/xlv55/kudzu-apr12/work/irix/lib/libc/libc_n32_M3/csu/crt1text.s":177, 
0x100012d8]

        % gdb -p 22896
        ...
        (gdb) where
        #0  0x00000000 in ?? ()
        #1  0x0000000c in ?? ()
        Backtrace stopped: previous frame identical to this frame (corrupt 
stack?)

Ideas?

-------------------------------------------------------------------------------
- Nelson H. F. Beebe                    Tel: +1 801 581 5254                  -
- University of Utah                    FAX: +1 801 581 4148                  -
- Department of Mathematics, 110 LCB    Internet e-mail: address@hidden  -
- 155 S 1400 E RM 233                       address@hidden  address@hidden -
- Salt Lake City, UT 84112-0090, USA    URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------



reply via email to

[Prev in Thread] Current Thread [Next in Thread]