Not sure if I got the right product/component, but I found quite a few crashes in recent MozillaTrunk data pointing to: Source File : ../../../../pr/src/io/prlayer.c line : 734 Here are stacks a user comments for crashes on Windows and Linux: Count Offset Real Signature [ 29 PR_GetIdentitiesLayer f5099fc7 - PR_GetIdentitiesLayer ] Crash date range: 2002-02-02 to 2002-02-04 Min/Max Seconds since last crash: 72 - 47636 Min/Max Runtime: 77 - 47636 Keyword List : Count Platform List 21 Windows NT 5.0 build 2195 3 Windows NT 4.0 build 1381 2 Windows 98 4.90 build 73010104 2 Windows 95 4.0 build 67109975 1 Windows 98 4.10 build 67766446 Count Build Id List 24 2002020211 5 2002020411 No of Unique Users 23 Stack trace(Frame) PR_GetIdentitiesLayer [../../../../pr/src/io/prlayer.c line 734] (2507316) URL: licensee.ygc.com.au (2507316) Comments: I just changed the proxy confs (2505832) URL: http://www.php.net/ (2505832) Comments: crashed in background I wasn't actually using Mozilla... (2483879) URL: www.hardforum.com (2483879) Comments: scrolling down..? (2437400) Comments: clicked on a link and crash occured ==================================================================================================== Count Offset Real Signature [ 1 PR_GetIdentitiesLayer() 7a0c9bac - PR_GetIdentitiesLayer() ] [ 1 PR_GetIdentitiesLayer() 5cb91976 - PR_GetIdentitiesLayer() ] [ 1 PR_GetIdentitiesLayer() 472f30ae - PR_GetIdentitiesLayer() ] [ 1 PR_GetIdentitiesLayer() 4115ac07 - PR_GetIdentitiesLayer() ] [ 1 PR_GetIdentitiesLayer() 3540fd78 - PR_GetIdentitiesLayer() ] [ 1 PR_GetIdentitiesLayer() 346c5a82 - PR_GetIdentitiesLayer() ] [ 1 PR_GetIdentitiesLayer() 0296ca02 - PR_GetIdentitiesLayer() ] [ 1 PR_GetIdentitiesLayer() 0110a9cf - PR_GetIdentitiesLayer() ] Crash date range: 2002-02-03 to 2002-02-04 Min/Max Seconds since last crash: 424 - 58111 Min/Max Runtime: 798 - 76157 Keyword List : Count Platform List 1 Linux 2.5.0 1 Linux 2.4.9-21 1 Linux 2.4.9-13 1 Linux 2.4.8-34.1mdk 1 Linux 2.4.3-12 1 Linux 2.4.17-ll 1 Linux 2.4.17 1 Linux 2.4.10-4GB Count Build Id List 4 2002020222 2 2002020121 1 2002020412 1 2002020208 No of Unique Users 8 Stack trace(Frame) PR_GetIdentitiesLayer() _pr_poll_with_poll() PR_Poll() nsSocketTransportService::Run() nsThread::Main() _pt_root() libpthread.so.0 + 0x7065 (0x401fa065) (2519201) Comments: Opened a link in one tab and immediately switched to another previously opened tab. (2462301) URL: http://www.geocities.com/SiliconValley/6603/mybac.htm (2462301) Comments: Opened URL in new tab. Page is partially loaded throbber is still throbbing...

*** Bug 123629 has been marked as a duplicate of this bug. ***

I've seen this crash a couple of times. Purify caught it as an arrays bound error. fd->higher->higher was 0xaeaeaeae within the PR_GetIdentitiesLayer. Dies in the second for loop. No real patern. Just occurs when I bounce around from Google and MyYahoo.

I am changing the product to Browser. The fact that the Mozilla client is crashing in an NSPR function does not mean it is an NSPR bug. This is most likely an application error. David, you said Purify caught it as an array bound error. Is it the PRPollDesc array that we step beyond the boundary?

Purify says the allocation occure in _PR_Getfd (prdfcach.c:138) which is the fd = PR_NEW(PRFileDesc); line. It says the block is 24 bytes. I don't think it's an actual array, I think this is just the stock error when something tries to read/write outside of an allocated block. What's odd is that part of this structure appears ok, the 0xaeaeaeae starts with the higher element. So it's not even like a one off problem. Maybe the structures had been freed, and then this area was reallocated. I'm attaching the Purify stacks. Unfortunately they're short. If I run across this again I'll get the stacks from VC++.

I just hit this crash too (2648921) using build: 2002020515 I wasn't using the computer at the time it crashed. Could have been caused by biff?

cc'ing darin

this may have been a fallout of the first patch for bug 86917, checked in on 2/1. the second patch, which fixed the crash regression, went in on 2/6. so, if we aren't seeing this anymore then i'd say this bug is a dupe of bug 86917. -> me

marking as a DUPE... please reopen if the problem persists. *** This bug has been marked as a duplicate of 86917 ***

*** Bug 123311 has been marked as a duplicate of this bug. ***