Closed Bug 296946 Opened 20 years ago Closed 17 years ago

Crash in nsViewManage::ComputeViewOffset()

Categories

(Core Graveyard :: Widget: BeOS, defect)

x86
BeOS
defect
Not set
critical

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: myob87, Unassigned)

Details

(Keywords: crash)

User-Agent:       Mozilla/5.0 (BeOS; U; BeOS BePC; en-US; rv:1.8b2) Gecko/20050321 Firefox/1.0+
Build Identifier: Mozilla/5.0 (BeOS; U; BeOS BePC; en-US; rv:1.8b2) Gecko/20050321 Firefox/1.0+

After browsing for some hours, Firefox on BeOS can randomly crash with a segment
violation in nsViewManager::ComputeViewOffset(). A stack crawl is provided:

loading symbols
segment violation occurred
nsViewManager::ComputeViewOffset(nsView const *):
ComputeViewOffset__13nsViewManagerPC6nsView:
+0020  ed9356c0:   *        20418b    movl    0x00000020(%ecx), %eax
firefox-bin:sc
   frame         retaddr
fcffb42c   ed930940  nsViewManager::BuildDisplayList(nsView *, nsRect const &,
int, int, nsVoidArray *, PLArenaPool &) + 00000028
fcffb4bc   ed9343c5  nsViewManager::BuildRenderingDisplayList(nsIView *,
nsRegion const &, nsVoidArray *, PLArenaPool &, int, int) + 0000003d
fcffb53c   ed92ce9a  nsViewManager::Refresh(nsView *, nsIRenderingContext *,
nsIRegion *, unsigned int) + 0000041a
fcffb69c   ed92fd05  nsViewManager::DispatchEvent(nsGUIEvent *, nsEventStatus *)
+ 00000531
fcffb74c   ed929a79  HandleEvent(nsGUIEvent *) + 00000049
fcffb77c   ed135ddf  nsWindow::DispatchEvent(nsGUIEvent *, nsEventStatus &) +
0000004f
fcffb7ac   ed135e5d  nsWindow::DispatchWindowEvent(nsGUIEvent *) + 00000039
fcffb7dc   ed133411  nsWindow::OnPaint(nsRect &) + 000001f5
fcffb89c   ed132919  nsWindow::CallMethod(MethodInfo *) + 00000855
fcffb96c   ed12944c  nsAppShell::Run(void) + 000000d0
fcffb9ac   ed18a60e  nsAppStartup::Run(void) + 0000002a
fcffb9dc   8000ca8c  XRE_main + 00002190
fcffc3fc   800072a6  main + 0000002a
fcffc42c   80006f75  _start + 00000061
firefox-bin:regs
 eax 72694661   ebp fcffb42c   cs 001b
 edx 786f6665   esi fcffb4b4   ss 0023
 ecx 00000059   edi 00000000   ds 0023
 ebx edadf0cc   esp fcffb404   es 0023
                               fs 3fc3
 eflags 00010206  eip ed9356c0
 trap_no 0000000e  error_code 00000004
firefox-bin:
                    

Reproducible: Sometimes

Steps to Reproduce:
1. Browse the internet for extremely long periods of time (18+ hours of browser
being open)
please file beos bugs in core:(widget|gfx):beos
please file beos bugs in core:(widget|gfx):beos
Assignee: nobody → beos
Component: OS Integration → Widget: BeOS
Product: Firefox → Core
QA Contact: os.integration → timeless
Version: unspecified → Trunk
Keywords: crash
Cian (or is it Kian?), does this problem also happen with newer builds? 20050321
is a few months old.

BTW, crasher bugs are Severity: Critical.

Prog.
Severity: minor → critical
My guess would be the cause is not deleting BViews somewhere - they all take
tokens in the app server, and when the tokens run out then you get a crash. A
problem with the transparency stuff made that viewable much quicker but don't
think that code ever made it into a production build.
Don't they usually tend to hang the whole system.

My guess is that this is an event arriving during/after destruction of a view
and improper control if mView exists/is attached to a window.
App server running out of threads for new windows freezes the system, I think
BView tokens are managed on an app-by-app basis. However IIRC you usually get a
"token space is full" message in the debugger.

The fact that it is only after an extended period suggests something is leaking
somewhere until a limit is hit.
This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/
Gerv (or automated thing), this is a BeOS bug. Keep off!
does anyone still see this?

reporter appears to be gone and there are no crashes in talkback for nsViewManage::ComputeViewOffset()
=> WFM based on no crashes in talkback
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Resolution: --- → WORKSFORME
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.