301987 - some tests fail

Status: NEW

(NSPR :: NSPR, defect)

Description

[Mikhail T.]

User-Agent:       Mozilla/5.0 (compatible; Konqueror/3.4; FreeBSD; X11; amd64) KHTML/3.4.1 (like Gecko)
Build Identifier: 

The test-suite appears to be largely abandoned and bit-rotten. But the 
pr/tests/addrstr seems to show a genuine bug: 
 
./addrstr 
converted bad addr 1:2:3:4:5:6:7::8 
converted bad addr 1:2:3:4:5:6::7:8 
FAIL 
 
Don't know, how best to fix it :-( 

Reproducible: Always

Comment 1

[Wan-Teh Chang]

Assuming you built NSPR on FreeBSD, which has inet_pton,
this means FreeBSD's inet_pton converts two bad IPv6
address strings "1:2:3:4:5:6:7::8" and "1:2:3:4:5:6::7:8"
successfully.  inet_pton should reject them because they
are too long; the "::" expands to at least one 16-bit
group of zeros.

You can try the following:
1. Report this bug to the FreeBSD maintainers; and
2. Remove the line:
       #define _PR_HAVE_INET_NTOP
   from mozilla/nsprpub/pr/include/md/_freebsd.h,
   and rebuild NSPR (cd into nsprpub and say
   "make clean; make").

We should add "addrstr" to runtests.sh so that this
test gets run regularly.

Comment 2

[Wan-Teh Chang]

Attachment: Patch to add printf statements after inet_pton calls

Please apply this patch to your source tree, rebuild NSPR,
run addrstr, and paste the output in this bug report.

Comment 3

[Mikhail T.]

Yes, indeed, this seems to be a FreeBSD problem :-( However, FreeBSD inet_pton    
implementation is straight from KAME:    
    
http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/net/inet_pton.c    
    
Some (most?) other OSes must be having the same problem...    
    
I reported the bug to FreeBSD:    
   http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/84106 
    
In addition to this, the following tests also fail on FreeBSD:   
         dlltest Segmentation fault (core dumped)   
        dlltest:        PR_LoadLibrary failed (-5977, 43, Cannot open   
"dll/libmy.so")   
   
        instrumt Segmentation fault (core dumped)   
   
     libfilename                        FAILED   
        libfilename:    PR_LoadLibrary failed   
   
   
Everything else (including forktest, nbconn, and poll_er) works and my 
FreeBSD/amd64 (single opteron-246). 
As far as dlltest, I can tell you, that build/pr/tests/dll/libmy.so.1 gets   
created, but there is no usual libmy.so symlink. If I create the link manually,   
both dltest and libfilename succeed.   
   
The instrumt test crashes with the following:   
(gdb) run   
Starting   
program: /var/ports/devel/nspr/work/nspr-4.6/mozilla/nsprpub/build/pr/tests/instrumt    
   
Program received signal SIGSEGV, Segmentation fault.   
0x0000000800671cc4 in pthread_testcancel () from /usr/lib/libpthread.so.1   
(gdb) where   
#0  0x0000000800671cc4 in pthread_testcancel () from /usr/lib/libpthread.so.1   
#1  0x0000000800661760 in sigaction () from /usr/lib/libpthread.so.1   
#2  0x000000080066a265 in pthread_mutexattr_init ()   
from /usr/lib/libpthread.so.1   
#3  0x0000000000000000 in ?? ()   
Error accessing memory address 0x7fffffbff000: Bad address.   
   
This seems to happen on the line 390 of instrumt.c:   
	t1 = PR_CreateThread(PR_USER_THREAD,   
			RecordTrace, NULL,    
			PR_PRIORITY_NORMAL,   
			PR_GLOBAL_THREAD,   
    		PR_UNJOINABLE_THREAD,   
			0);   
   
The pthread_mutexattr_init on the gdb's stack above is, actually, the   
_PT_PTHREAD_CREATE() call on line pr/src/pthreads/ptthread.c:455. This crash  
happens on both FreeBSD/i386 and FreeBSD/amd64. 
 
On my dual PentiumII machine (FreeBSD/i386) the following other tests fail: 
        forktest                        FAILED 
        forktest:       Accepting connection at port 52656 
        forktest:       Wait one second before connect 
        forktest:       Connecting to port 52656 
        forktest:       Writing message "Hello world!" 
        forktest:       Received "Hello world!" from the client 
        forktest:       The message is received correctly 
        forktest:       Fork succeeded.  Parent process continues. 
        forktest:       Accepting connection at port 60779 
        forktest:       Wait one second before connect 
        forktest:       Fork succeeded.  Child process continues. 
        forktest:       Accepting connection at port 62560 
        forktest:       Connecting to port 60779 
        forktest:       Writing message "Hello world!" 
        forktest:       Received "Hello world!" from the client 
        forktest:       The message is received correctly 
        forktest:       PR_Accept failed: error code -5990 
        forktest:       Child process exits. 
        forktest:       Parent process exits. 
        forktest:       FAILED 
 
      io_timeout                        FAILED 
        io_timeout:     test with global bound thread 
        io_timeout:     thread id 0, scope GLOBAL_BOUND scope 
        io_timeout:     test with local thread 
        io_timeout:     thread id 0, scope GLOBAL scope 
        io_timeout:     test with global thread 
        io_timeout:     thread id 0, scope GLOBAL scope 
 
Do these, perhaps, have race conditions or some other assumptions, that don't 
hold on multi-CPU machines? 

Comment 4

[Mikhail T.]

Yes, there is a race in forktest. Adding a one second delay before PR_Accept 
solves the problem: 
 
@@ -185,2 +185,5 @@ 
     } 
+    printf("Wait one second before accept\n"); 
+    fflush(stdout); 
+    PR_Sleep(PR_SecondsToInterval(1)); 
     printf("Accepting connection at port %hu\n", PR_ntohs(addr.inet.port)); 
 

Comment 5

[Mikhail T.]

Attachment: Work-around for io_timeout's occasional failures

io_timeout was failing because I had a web-server running on the machine
listening on port 8000...

The attached patch changes the BASE_PORT from the collision-prone 8000 to 38011
(for want of a better algorithm for free-port searching), improves diagnostics
of bind() failure, and makes EADDRINUSE a non-failure, so that the test
sequence does not fail for reasons outside of NSPR.

Comment 6

[Phoenix]

First part of this bug fixed long ago on FreeBSD side, does second still matters?

Comment 7

[Wayne Mery (:wsmwk)]

Mikhail T, can you offer guidance on ....

(In reply to Phoenix from comment #6)
> First part of this bug fixed long ago on FreeBSD side, does second still
> matters?

Comment 8

[Mikhail T.]

Unfortunately, I never understood, what Phoenix meant by "first part" and "second part".

FWIW, I just ran the tests here and they all succeeded except:

          fdcach                        FAILED
        fdcach: fd stack malfunctioned

Comment 9

[Phoenix]

(In reply to Mikhail T. from comment #8)
> Unfortunately, I never understood, what Phoenix meant by "first part" and
> "second part".
You provided two patches, at the time of writing first patch was present in FreeBSD ports "files" folder

Comment 10

[Mikhail T.]

(In reply to Phoenix from comment #9)
> (In reply to Mikhail T. from comment #8)
> > Unfortunately, I never understood, what Phoenix meant by "first part" and
> > "second part".
> You provided two patches, at the time of writing first patch was present in
> FreeBSD ports "files" folder

It was present in the files/ folder, because I put it there :-) Well, marcus@ did on my prodding.

My two hunks (single patch) -- along with a whole bunch of others -- remain in our devel/nspr port:

      https://svnweb.freebsd.org/ports/head/devel/nspr/files/patch-tests?view=markup

But we are not discussing the FreeBSD port here, but an NSPR problem. That FreeBSD (partially) solves it, is irrelevant -- Mozilla/NSPR developers ought to improve their code so OS-specific packagers do not have to maintain patches for decades... NSPR's self-tests remain unreliable, which keeps people from routinely using them, thus making them less useful than they deserve.

Comment 11

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee is inactive on Bugzilla, so the assignee is being reset.