assert error: expression = n > 0

RESOLVED FIXED in 4.2

Status

defect
P1
normal
RESOLVED FIXED
19 years ago
19 years ago

People

(Reporter: colin, Assigned: colin)

Tracking

other
DEC
OpenVMS

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

Assignee

Description

19 years ago
I've heard two people report the same problem, so I'm opening a bug report on 
it. 

When visiting a page the following appears on the console: 

  assert error: expression = n > 0 

and is closely followed by an accvio 

In each case what was expected was a popup asking where to download a plugin 
from. 

Case 1 
OpenVMS V7.2-1 with all the latest ECO's 
TCP/IP 5.0A ECO 112 
M0.7 and M0.8 
Internal Compaq page 
Insight page containing Java 
Should cause popup to appear asking where to download Java from 
Instead get assert error 

Case 2 
OpenVMS V7.2-1 
DWMOTIF V1.2-5 with display via DECnet to V7.2-1/V1.2-4 system 
M0.7 and M0.8 
www.compaq-signup.com 
page contains Shockwave Flash 
Should cause popup to appear asking where to download Shockwave from 
Instead get assert error 

There's something going on here....
Assignee

Comment 1

19 years ago
Seems that its only happening on V7.2-1 systems.

Wonder if its stack size related???
Status: NEW → ASSIGNED
Assignee

Comment 2

19 years ago
Modified NSPR to ensure that the stack size is always AT LEAST 128KB. Sent image 
to reporters for testing. The reporter from case 2 tells me it fixed the 
problem. Still waiting to hear from case 1.
Assignee

Comment 3

19 years ago
Wan-Teh, I need to change _PR_CreateThread so that the stack size passed in to 
pthread_attr_setstacksize can never be LESS than a specific amount. I was 
thinking about making this MINIMUM be something that is picked up at run 
time (once, via a call to getenv), with zero or no value meaning "no minimum" 
(ie. today's current behavior). 

I think the overhead of this code will be minimal and the opportunity to change 
the minimum stack size "on the fly" a benefit for all platforms. I'm sure that 
sooner or later some other O/S is going to run into this same problem.

What do you think?

Updated

19 years ago
Component: Browser-General → NSPR
Product: Browser → NSPR

Updated

19 years ago
Priority: -- → P1
Target Milestone: --- → 4.2

Comment 5

19 years ago
Colin, your patch works but it would require us to
document the two new environment variables.  I hate
writing documentation ;-)  Therefore, I'm going to
propose another solution which allows you to specify
a platform-specific minimum thread stack size at
compile time.  My proposal does not allow you to
configure the minimum stack size at run time, but I
think few applications need that flexibility.
Assignee

Comment 7

19 years ago
Why is the default stack size set to 64*1024 where there's a perfectly good 
#define that we could use - _MD_DEFAULT_STACK_SIZE

Any reason?
Assignee

Comment 8

19 years ago
Should we do this:

#ifdef _MD_DEFAULT_STACK_SIZE
     if (0 == stackSize) stackSize = _MD_DEFAULT_STACK_SIZE;
#endif
#ifdef _MD_MINIMUM_STACK_SIZE
    if (stackSize < _MD_MINIMUM_STACK_SIZE) stackSize = _MD_MINIMUM_STACK_SIZE;
#endif

Comment 9

19 years ago
_MD_DEFAULT_STACK_SIZE is only used by "classic" NSPR.
The pthreads version of NSPR does not use that macro.
It just uses the hardcoded value 64*1024 for all platforms.

_MD_MINIMUM_STACK_SIZE was originally added for classic
NSPR too.  My patch generalized it for use by pthreads NSPR.
I could also have the pthreads version use _MD_DEFAULT_STACK_SIZE
too, but that would change the current behavior.  That's why I
didn't do that.
Assignee

Comment 10

19 years ago
Wan-Teh, I tried out your patch and it does the job. I was able to stop in the 
debugger and see that each pthread stack was at least 128K. Please go ahead and 
check it in.

BTW, I always kind of liked the idea/concept of UNdocumented environment 
variables. Basically, never add a constant if you think you'll ever need to 
change it again. Saved my butt many a time. NSPR seems to already have a few of 
these itself:

NSPR_FD_CACHE_SIZE_LOW
NSPR_FD_CACHE_SIZE_HIGH
NSPR_AIX_SEND_FILE_USE_DISABLED
NSPR_NOCLOCK
NSPR_SIGSEGV_HANDLE
NSPR_SIGABRT_HANDLE
NSPR_SIGBUS_HANDLE
NSPR_NO_MMAP
NSPR_ATOMIC_HASH_LOCKS
NSPR_NATIVE_THREADS_ONLY{
NSPR_INHERIT_FDS
NSPR_NUM_IO_QUEUES

That was why I thought adding two more environment variables was the 
preferred/best way to handle this. But if you don't like the concept of 
undocumented run-time variables, then I understand.
Assignee

Comment 11

19 years ago
The reporter of "case 1" just sent me mail:

  Insight mgr works fine (and fast!!) except for the masstorage section that
  still bomb on OPCCUS 

I've asked for information about the OPCCUS so I can determine if that's the 
same problem or a different one.

Comment 12

19 years ago
I checked in my patch (attachment id=25836) on the tip
and NSPRPUB_CLIENT_BRANCH of NSPR.
Assignee

Comment 13

19 years ago
I believe the assert problem is fixed, so closing this bug report.
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.