Closed Bug 189485 Opened 22 years ago Closed 16 years ago

A crash occurs when OBJECT'S data attribute value is empty

Categories

(Core Graveyard :: Plug-ins, defect, P2)

defect

Tracking

(Not tracked)

RESOLVED FIXED
Future

People

(Reporter: chrispetersen, Assigned: danielle.pham)

Details

(Keywords: crash, testcase)

Attachments

(3 files)

Build: 2003-01-15-07
Platform: All
Expected Results: The application should not crash
What I got: Application crash when intializing the OBJECT element

Steps to reproduce:

1) Open attached test case which contains a OBJECT referencing a java applet via
CLASSID. The test case includes a DATA="" attribute.
2) Application crashes.
This problem reproduces under Win32 trunk , MACH-0 OS X trunk, CFM OS X trunk
and latest Chimera build.
Crash on

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030114 on WinXP.

(do not crash on systems without Java plugin).
confirming crash using build 20030117 on Linux + JRE 1.4.1_01.
Keywords: crash
Priority: -- → P2
Target Milestone: --- → Future
Keywords: testcase
This is WFM on Debian.
QA Contact: shrir
TB2104382K with winxp 2004111204
Keywords: talkbackid
Whiteboard: TB2104382K
Xiaobin it looks like you have written the code
(/deploy/src/plugin/share/adapter/ns7) where it crashes could you please look at it.
Assignee: peterlubczynski-bugs → Xiaobin.Lu
I filed a bug in suns database which is not public visible yet (internal id
338622) to get some traction on this
Keywords: talkbackid
Whiteboard: TB2104382K
It does not seem that any browser can be able to render the testcase 
attachment.html (https://bugzilla.mozilla.org/attachment.cgi?id=111844) 
provided in bugzilla 189485 (https://bugzilla.mozilla.org/show_bug.cgi?
id=189485).

I tried it with IE6.0, Mozilla1.8, Firefox1.0.6.  Regardless of the browser 
used, only the text "This text should appear if the browser can't render this 
applet object" and no applet is loaded, no crash can be seen.

I also asked another engineer (Xiaobin Lu, who's originally the owner of 
bugzilla bug# 189485) to run this testcase and he also got the same result 
with me.

I looked into the contents of the crash stack trace under MAC OS attached in 
189485 (https://bugzilla.mozilla.org/attachment.cgi?id=111842).  The stack 
trace shows old JPI code that no longer exist in JRE 1.4.2, 1.5.0, 1.6.0.

So the questions are:

1) Which JRE version that was used when the crash happened?
2) Can you resubmit the testcase with which we can be able to see the crash.  
Please also attach JitterText.class applet.
3) Does problem still exists with our latest JRE updates  (1.4.2_08, 1.5.0_04)?

Without these information, I cannot proceed to work on this bug.
danielle.pham@sun.com
danielle.pham@sun.com: macosx normally uses 1.3 for mrj unless you use jep
This thing does crash as before on winxp the firefox nightly. I just filed a new
talkback.
http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=TB9382117G

this is with Java Version 1.5.0 (Build 1.5.0_04-b05)
Danielle,

  Would you please take over the ownership of this bug?
  Thanks.
Assignee: Xiaobin.Lu → danielle.pham
The Problem still exists in Firefox 2.0.0.3 and is not restricted to the Java plugin. The plugin of Adobe Reader 8.0.0 also crashes when the parameter "data" is empty. Internet Explorer 7 simply shows "Crash through object tag" and the inner text instead of the object.
The general problem seems to be that Firefox crashes when a plugin crashes. FF should be able to safely handle crashing plugins.
On my 2007-05-09 and 2007-05-30 Linux builds of Firefox 3.0, *any* object element with an empty (not absent) data attribute can freeze Firefox. Even something as simple as this:
<object data=""></object>
This behavior is not present in Firefox 2.0.

Sometimes the object will just steal the content of the following object, shifting the content of all objects by one, leaving the last object with an error page about not finding "<path>/undefined". If there are no object elements following to steal from, Firefox will always freeze, and sometimes it will freeze even if there are following valid objects. 

This may be due to a different issue, since plugins shouldn't be involved here. It could have something to do with bug 96976.

I think it would be a serious error to release Firefox 3.0 while it can be frozen with just 25 characters.
Attached Test Case: 

  189485_String_Term_Crash.html 

  Open test cast with affected Firefox version on confirmed operating system       
  using one of the tested Java versions.

  Test case demonstrates crash, hang, or improper rending of an object 
  containing an empty attribute value.

Confirmed affected operating systems: 

  Windows XP SP1
  Fedora Core 4

Test with Java versions: 

  DK/JRE 5.0 update 5
  DK/JRE 5.0 update 11
  J2SDK/J2RE 1.4.1_02
  J2SDK/J2RE 1.4.2_01
  J2SDK/J2RE 1.4.2_14

Firefox versions:

  Firefox 2.0.0.6
  Firefox 3

Klocwork source code analysis report:

  Defect Name: 
    Result of function that may return NULL will be dereferenced.

  Location: 

    firefox/ firefox2.0.0.6/mozilla/modules/plugin/base/src/nsPluginHostImpl.cpp   
    line: 6462

  Details:
    Pointer 's++' returned from call to function 'ElementAt' at line 6454 may be
    NULL and will be dereferenced at line 6462.

Traceback:

nsPluginHostImpl.cpp:6351: !inPostData|| !outPostData|| !outPostDataLen is false
nsPluginHostImpl.cpp:6437: headersLen is true
nsPluginHostImpl.cpp:6447: ! ( *outPostData=p= (char* )nsMemory::Alloc(newBufferLen) ) is false
nsPluginHostImpl.cpp:6452: cntSingleLF is true
nsPluginHostImpl.cpp:6453: i<cntSingleLF is true
nsPluginHostImpl.cpp:6454: 'plf' has a NULL value, which is returned by function 'ElementAt'.
nsPluginHostImpl.cpp:6461: s:=plf
nsPluginHostImpl.cpp:6462: 's++' is explicitly dereferenced.

Comments:

  I am part of the Professional Services team at Klocwork and was asked to use    
  the Klocwork source code analysis tool on some open source projects. From the
  list of defects found in the Firefox 2.0.0.6 source, I believe this particular
  defect is related to the empty object data attribute.

  The malicious object is rendered properly on Windows Vista using Firefox 
  version: 2.0.0.6, Java build 1.5.0_12-b04 full JDK. The same setup on Windows 
  XP results in a crash.

  If the test case is opened while Firefox is already loaded, Firefox might 
  simply hang instead of crash. If Firefox is opened through opening of the test
  case, the crash is consistent.

  Internet Explorer 7 is unable to render the malformed object properly, but
  does not result in a crash.

  Suggested severity is critical.

  A duplicate of this defect is also incorrectly reported as irreproducible in
  Sun’s bug tracking database.
I could reproduce the problem.
Will take a look at it.
I put an engineering build JRE bundle with this fix for Windows on:

http://www.annepoon.com/java/jre-6u4-sep14.exe

Please verify if problem is gone with this bundle.

The corresponding Sun bug ID for this is 6604926.
I'll try to get fix in to the next update release of 6.0 (6u4).

Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: