Closed Bug 110248 Opened 23 years ago Closed 23 years ago

segmentation fault on http://www.ebolt.hu/

Categories

(Core Graveyard :: Plug-ins, defect)

x86
Linux
defect
Not set
critical

Tracking

(Not tracked)

VERIFIED DUPLICATE of bug 58937

People

(Reporter: nagyt, Assigned: srgchrpv)

References

()

Details

(Keywords: crash)

Attachments

(3 files)

mozilla-2001111414_trunk-0_rh7 amd all versions before makes segmentatiln folt
on URL http://www.ebolt.hu.
Linux problem only? WFM 2001 11 14 03 / Win2k.
WFM 2001111408/Linux.
wfm with win2k build 20011114..

Reporter:
Please use a talkback enabled build and poste the talkback ID of this crash.
(Run mozilla/bin/comonents/talkback after the crash to get the talkback ID)
wfm using build 2001111403 on Win2k.
There's Flash on this page, reporter, can you load any other Flash-enabled site
such as http://www.eye4u.com/ ? Do you have Flash installed ?

Can you try a Talkback-enabled build and post Talkback ID when crashing ?
Keywords: crash
1. It seems to be Linux problem only.
2. Flash works fine, I have Shockwave Flash 5.0 r47
 installed.
3. I installed a talkback enabled build:
mozilla-i686-pc-linux-gnu-0.9.5-sea.tar.gz 10154302 bytes.
This version crashed also, but nothing special happens. I did not find
components/talkback either. Give me the right URL to install, please.          
         
Reporter: This build should be talkback-enabled:
http://ftp.mozilla.org/pub/mozilla/nightly/latest/mozilla-i686-pc-linux-gnu-sea.tar.gz
(as always, be sure to delete your old Mozilla directory before installing the
new one)
Keywords: stackwanted
Severity: normal → critical
Summary: segmentation fault on http://www.ebolt.hu → segmentation fault on http://www.ebolt.hu/
I've sent the talkback report to Alex.
Talkback couldn't have gone through our proxy server, however manual proxy for
HTTP was set and automatic proxy configuration was unchecked.
'Create a New Attachment' in Bugzilla form does not work, it always missis the
path of the file to attach.
E-mail from reporter: 

> I've downloaded the talkback-enabled version, but unfortunately the talkback 
> program wasn't able to go through our proxy server. Than I tried to upload the 
> saved talkback report as attachment in bugzilla, it was also unsuccessfull. So I 
> send it to you.
> 
> Tibor

Huge-ass attachment forthcoming.
I keep getting the error "You did not specify a file to attach" :-/. Is this a
known-problem with 2001111603?
Alex, there's a recent bug with File Upload: bug 110613.
However, wfm using build 2001111706 on Linux.
However, this is like no talkback report that I've ever seen. Might not be
useful.
Reporter, can you try crashing again and post another Talkback ID from a fresh
profile ? ('mozilla -profilemanager')
Reporter,

Did you try setting Proxy settings in Talkback directly ?

Launch Talkback with '<mozilla-dir>/components/talkback/talkback' and then go
into Settings -> Manual proxy.
Olivier,

the answer to #11: the file I sent was created by the talkback program. I
have pressed the button 'Details', than 'Save as'. Using a new profile did not
make any differences.

The answer to #12: As I wrote in #7 I have set proxy in talkback directly. How
is it possible, that talkback did not ask me for proxy user name and password?
I've installed mozilla on Linux machine with dial-up internet connection,
without proxy. The problem was successfully sent with talkback.

Incident ID: TB38218241Y
It seems that the problem is caused by the flashplayer plugin.
If I remove libflashplayer.so and ShockwaveFlash.class from the plugin
directory, than everything is OK. How it is possible, that the flash plugin is
not requested in that case on www.ebolt.hu?
CC: stephend@netscape.com, for talkback retrieval, please (TB38218241Y).
Keywords: stackwanted
Stack Signature  libc.so.6 + 0x72500 (0x4050e500) b30604c8
Bug ID
Trigger Time 2001-11-19 02:05:24
Email Address nagyt@otpbank.hu
URL visited www.ebolt.hu
User Comments bugzilla #110248
Build ID 2001111521
Product ID MozillaTrunk
Platform
Operating System LinuxIntel
Module
Trigger Reason SIGSEGV: Segmentation Fault: (signal 11)
Stack Trace
libc.so.6 + 0x72500 (0x4050e500)
libc.so.6 + 0x72253 (0x4050e253)
libX11.so.6 + 0x20d07 (0x403bbd07)
libflashplayer.so + 0x39c4d (0x41178c4d)
libXt.so.6 + 0x14c99 (0x410a1c99)
libXt.so.6 + 0x14b9e (0x410a1b9e)
libXt.so.6 + 0x14b52 (0x410a1b52)
libXt.so.6 + 0x15052 (0x410a2052)
libXt.so.6 + 0x151fd (0x410a21fd)
libXt.so.6 + 0x153a9 (0x410a23a9)
gtk_xtbin_destroy()
libgtk-1.2.so.0 + 0x93bd3 (0x4028ebd3)
libgtk-1.2.so.0 + 0xc3cfd (0x402becfd)
libgtk-1.2.so.0 + 0xc1c17 (0x402bcc17)
libgtk-1.2.so.0 + 0xa59cc (0x402a09cc)
libgtk-1.2.so.0 + 0xfe548 (0x402f9548)
gtk_xtbin_shutdown()
libgtk-1.2.so.0 + 0xa596a (0x402a096a)
libgtk-1.2.so.0 + 0xf6ae9 (0x402f1ae9)
ns4xPluginInstance::SetWindow()
nsObjectFrame::DidReflow()
nsLineLayout::ReflowFrame()
nsInlineFrame::ReflowInlineFrame()
nsInlineFrame::ReflowFrames()
nsInlineFrame::Reflow()
nsLineLayout::ReflowFrame()
nsBlockFrame::ReflowInlineFrame()
nsBlockFrame::DoReflowInlineFrames()
nsBlockFrame::DoReflowInlineFramesAuto()
nsBlockFrame::ReflowInlineFrames()
nsBlockFrame::ReflowLine()
nsBlockFrame::ReflowDirtyLines()
nsBlockFrame::Reflow()
nsBlockReflowContext::DoReflowBlock()
nsBlockReflowContext::ReflowBlock()
nsBlockFrame::ReflowBlockFrame()
nsBlockFrame::ReflowLine()
nsBlockFrame::ReflowDirtyLines()
nsBlockFrame::Reflow()
nsContainerFrame::ReflowChild()
nsTableCellFrame::Reflow()
nsContainerFrame::ReflowChild()
nsTableRowFrame::ReflowChildren()
nsTableRowFrame::Reflow()
nsContainerFrame::ReflowChild()
nsTableRowGroupFrame::ReflowChildren()
nsTableRowGroupFrame::Reflow()
nsContainerFrame::ReflowChild()
nsTableFrame::ReflowChildren()
nsTableFrame::ReflowTable()
nsTableFrame::Reflow()
nsContainerFrame::ReflowChild()
nsTableOuterFrame::OuterReflowChild()
nsTableOuterFrame::IR_InnerTableReflow()
nsTableOuterFrame::IR_TargetIsInnerTableFrame()
nsTableOuterFrame::IR_TargetIsChild()
nsTableOuterFrame::IncrementalReflow()
nsTableOuterFrame::Reflow()
nsBlockReflowContext::DoReflowBlock()
nsBlockReflowContext::ReflowBlock()
nsBlockFrame::ReflowBlockFrame()
nsBlockFrame::ReflowLine()
nsBlockFrame::ReflowDirtyLines()
nsBlockFrame::Reflow()
nsBlockReflowContext::DoReflowBlock()
nsBlockReflowContext::ReflowBlock()
nsBlockFrame::ReflowBlockFrame()
nsBlockFrame::ReflowLine()
nsBlockFrame::ReflowDirtyLines()
nsBlockFrame::Reflow()
nsContainerFrame::ReflowChild()
CanvasFrame::Reflow()
nsBoxToBlockAdaptor::Reflow()
nsBoxToBlockAdaptor::DoLayout()
nsBox::Layout()
nsScrollBoxFrame::DoLayout()
nsBox::Layout()
nsContainerBox::LayoutChildAt()
nsGfxScrollFrameInner::LayoutBox()
nsGfxScrollFrameInner::Layout()
nsGfxScrollFrame::DoLayout()
nsBox::Layout()
nsBoxFrame::Reflow()
nsGfxScrollFrame::Reflow()
nsContainerFrame::ReflowChild()
ViewportFrame::Reflow()
nsHTMLReflowCommand::Dispatch()
PresShell::ProcessReflowCommand()
PresShell::ProcessReflowCommands()
HandlePLEvent()
PL_HandleEvent()
PL_ProcessPendingEvents()
nsEventQueueImpl::ProcessPendingEvents()
event_processor_callback()
our_gdk_io_invoke()
libglib-1.2.so.0 + 0xf350 (0x4036f350)
libglib-1.2.so.0 + 0x10be6 (0x40370be6)
libglib-1.2.so.0 + 0x11213 (0x40371213)
libglib-1.2.so.0 + 0x113dc (0x403713dc)
libgtk-1.2.so.0 + 0x9204c (0x4028d04c) 
Marking NEW. Possible dupe: bug 109340.

-> Networking: HTTP, but punt as needed
Assignee: asa → darin
Status: UNCONFIRMED → NEW
Component: Browser-General → Networking: HTTP
Ever confirmed: true
QA Contact: doronr → tever
I've tried an URL reported in bug #109340.
Mozilla crashed.
Talkback report sent, incident ID TB38264619Y
from the stack trace, this looks like it has something to do with the flash plugin.

-> plugins
Assignee: darin → av
Component: Networking: HTTP → Plug-ins
QA Contact: tever → shrir
Looks like it's doing some gtk stuff around SetWindow(). There is a bunch of
UNIX-only code there...over to Serge for a look...

libgtk-1.2.so.0 + 0xf6ae9 (0x402f1ae9)
ns4xPluginInstance::SetWindow()
nsObjectFrame::DidReflow()
Assignee: av → serge
Reporter, would plase look at the patch for bug #108347. I think
that the reason of these bugs are the same.
I have downloaded the full source tree of mozilla today, compiled it, installed

Sergey's patch and I got the following result (segmentation fault): see
attachment.
Yes, I can suspect this is most likely because of window->width[height] < 0;
I was able to see negative window->width value on ebolt.hu only once in very 
first debug session:(
Tibor, would you try to apply an attachment 61965 [details] [diff] [review] from bug #108347, which does 
check for negatives, and it would be more useful if you post the crash stack 
trace here, instead of debug output.
Thanks.
I have tried the suggested patch, nothing have been changed.
How can I create a stack trace? Not even a core file has been created, however
'ulimit -c' is set to 'unlimited' and I could also successfully creat a core
file with a dummy C program. (p=(char*)0; *p=0;)

By the way. UNBELIVEABLY!!! We are working with remote X servers. However if I
start mozilla on the display of the internet gateway (locally) it works!!!

Our normal configuration (mozilla crashes):
-------------------------------------------------------------------
ntibor                     dell632               pcwall
(my workstation)           (common server)       (internet gateway)

X -query dell632
                           ssh -X pcwall
                                                 mozilla
--------------------------------------------------------------------
I tried also the following configurations (mozilla crashes)
-------------------------------------------------------------------
ntibor                     dell632               pcwall
(my workstation)           (common server)       (internet gateway)

X -query dell632
                           xhost +
                           ssh pcwall
                                                 export DISPLAY=ntibor:1
                                                 mozilla
--------------------------------------------------------------------
ntibor                                           pcwall
(my workstation)                                 (internet gateway)

startx
ssh -X pcwall                           
                                                 mozilla
--------------------------------------------------------------------

ntibor                                           pcwall
(my workstation)                                 (internet gateway)

startx
xhost +
ssh pcwall                           
                                                 export DISPLAY=ntibor:1
                                                 mozilla
--------------------------------------------------------------------

UNBELIVEABLY!!! If mozilla is using the display of the same machine
where it is running, it works, also in the following configuration,
with ssh tunneling:
-------------------------------------------------------------------
                           dell632               pcwall
                           (common server)       (internet gateway)
                                                 XDM login
                                                 ssh -X dell632
                           ssh -X pcwall
                                                 mozilla
I got a stacktrace by starting 'mozilla -g'. 

By the way, another configuration (mozilla crashes):
-------------------------------------------------------------------
ntibor						 pcwall
(my workstation)				 (internet gateway)
 
X -query pcwall
 
						 mozilla
--------------------------------------------------------------------
Tibor, thank you for the stack trace, it looks like some memory corruption 
causes the crash.
if you are crashing only with remote display this is known issue bug# 58937
Sergey, you are right. As I see this is the same issue. (bug# 58937)

.
I'm resolving this as a dup of 58937

*** This bug has been marked as a duplicate of 58937 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
mass duplicate verifications . For filtering purposes, pls use keywd
"massdupverification"

Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: