74080 - hubbe.net - Plugger and .mid causes SIGPIPE crash in libX11

Status: RESOLVED FIXED

(Tech Evangelism Graveyard :: English US, defect, P3)

Description

[Matthew Cline]

Build 2001032921, Linux 2.4.2-ac20 i686, RedHat 6.1, XFree 4.0.2

When opening the given URL, Mozilla crashes from a SIGPIPE signal, with
the following stack trace:

#0  0x40324be4 in __libc_write () from /lib/libc.so.6
#1  0x401e8cfc in __DTOR_END__ () at eval.c:41
#2  0x40759ef6 in _X11TransGetHostname () from /usr/X11R6/lib/libX11.so.6
#3  0x40759cc7 in _X11TransWrite () from /usr/X11R6/lib/libX11.so.6
#4  0x40739bfd in _XGetAsyncData () from /usr/X11R6/lib/libX11.so.6
#5  0x40739cfd in _XEventsQueued () from /usr/X11R6/lib/libX11.so.6
#6  0x4072d88e in XPending () from /usr/X11R6/lib/libX11.so.6
#7  0x406ad9c6 in gdk_events_init () from /usr/lib/libgdk-1.2.so.0
#8  0x406e208c in g_main_run () from /usr/lib/libglib-1.2.so.0

Comment 1

[Matthew Cline]

When run with a debug build made from a CVS tree pulled on March 27,
this is output right before the crash:

<<<<<<
WARNING: Cached data size does not match the Content-Length header, file
nsHTTPChannel.cpp, line 1140
WARNING: Cached data size does not match the Content-Length header, file
nsHTTPChannel.cpp, line 1140
WARNING: Cached data size does not match the Content-Length header, file
nsHTTPChannel.cpp, line 1140
WARNING: Cached data size does not match the Content-Length header, file
nsHTTPChannel.cpp, line 1140
WARNING: Cached data size does not match the Content-Length header, file
nsHTTPChannel.cpp, line 1140
Assertion failure: PT_TRYLOCK_BUSY == rv, at ptsynch.c:487
Gdk-ERROR **: X connection to :0.0 broken (explicit kill or server shutdown).
Assertion failure: PT_TRYLOCK_BUSY == rv, at ptsynch.c:487
>>>>>>

Also, the crash happens in a different place, and because of an assertion
rather than a SIGPIPE:

#0  0x406a9131 in __kill () from /lib/libc.so.6
#1  0x406441ca in raise (sig=6) at signals.c:65
#2  0x406aa518 in abort () at ../sysdeps/generic/abort.c:88
#3  0x405f8cee in PR_Assert (s=0x40625f70 "PT_TRYLOCK_BUSY == rv", 
    file=0x40625ca0 "ptsynch.c", ln=487) at prlog.c:477
#4  0x40612bc7 in PR_EnterMonitor (mon=0x8092bc0) at ptsynch.c:487
#5  0x40175cc7 in free (ptr=0x8092bc0) at nsTraceMalloc.c:1379
#6  0x405ff137 in PR_Free (ptr=0x8092bc0) at prmem.c:66
#7  0x40612a54 in PR_DestroyMonitor (mon=0x8092bc0) at ptsynch.c:450
#8  0x401763a0 in NS_TraceMallocShutdown () at nsTraceMalloc.c:1558
#9  0x406ab766 in exit (status=1) at exit.c:54
#10 0x40932b42 in gdk_set_sm_client_id () from /usr/lib/libgdk-1.2.so.0
#11 0x40f14c63 in _XGetAsyncData () from /usr/X11R6/lib/libX11.so.6
#12 0x40f17f51 in _XFlush () from /usr/X11R6/lib/libX11.so.6
#13 0x40ef72c9 in XCopyArea () from /usr/X11R6/lib/libX11.so.6
#14 0x40954d98 in gdk_window_copy_area () from /usr/lib/libgdk-1.2.so.0
#15 0x427620d1 in nsViewManager::Refresh (this=0x82d2b28, aView=0x82d2c70, 
    aContext=0x8a0b5b0, rect=0xbfffefb8, aUpdateFlags=1)
    at nsViewManager.cpp:886
#16 0x42764c47 in nsViewManager::DispatchEvent (this=0x82d2b28, 
    aEvent=0xbffff130, aStatus=0xbffff014) at nsViewManager.cpp:1891
#17 0x42757ffd in HandleEvent (aEvent=0xbffff130) at nsView.cpp:67
#18 0x40cf7a1b in nsWidget::DispatchEvent (this=0x82d2cd8, aEvent=0xbffff130, 
    aStatus=@0xbffff0d4) at nsWidget.cpp:1471
#19 0x40cf7613 in nsWidget::DispatchWindowEvent (this=0x82d2cd8, 
    event=0xbffff130) at nsWidget.cpp:1362
#20 0x40cfe221 in nsWindow::DoPaint (this=0x82d2cd8, aX=835, aY=31, aWidth=33, 
    aHeight=33, aClipRegion=0x82d2e48) at nsWindow.cpp:705
#21 0x40cfe3f3 in nsWindow::Update (this=0x82d2cd8) at nsWindow.cpp:741
#22 0x40cfdf62 in nsWindow::UpdateIdle (data=0x0) at nsWindow.cpp:617
#23 0x40ebd97b in g_idle_dispatch () from /usr/lib/libglib-1.2.so.0
#24 0x40ebc847 in g_main_dispatch () from /usr/lib/libglib-1.2.so.0
#25 0x40ebcec1 in g_main_iterate () from /usr/lib/libglib-1.2.so.0
#26 0x40ebd08c in g_main_run () from /usr/lib/libglib-1.2.so.0

Comment 2

[Asa Dotzler [:asa]]

unable to elicit a crash or a hang with 04/03 build on linux or win32

Comment 3

[Matthew Cline]

Using build 2001040311 on Linux, I get the exact same behavior.  strace
on the X server shows nothing useful, ltrace causes X to hang, and I can't
figure out how to get X to produce debugging output (I'm using xdm).  If
anyone can tell me how to get X to produce debugging output, or any other
way of getting useful info about this bug, I'd apreciate it.

Comment 4

[Matthew Cline]

It appears that the Plugger plugin, when trying to load the .mid file in
in the given URL, causes the crash.  Netscape 4.76, using the same plugger.so
file, doesn't crash, although it doesn't sucsessfuly play the MIDI file.

I've attempted to run mozilla with the the X command line flag "-synchronous"
to try and better debug it, but I haven't gotten anywhere with that.

Comment 5

[Asa Dotzler [:asa]]

setting default owners.

Comment 6

[av (gone)]

Adding serge

Comment 7

[Matthew Cline]

Ignore the stack trace in my second comment, since it wasn't done with
Mozilla's X connection being in synchronous mode.  I've gotten a
useful stack trace under synchronous mode, and it looks like the
crash is happening under the X XIE extension, which would put this
under imagelib, but it only happens if the plugger plugin is loaded,
so maybe it should stay under plugins?  I don't know.

Use the "xdpyinfo" to see what extensions X is using; if XIE isn't
among them, you might not have a problem.  This might be related to
the bug 74293, which was also having problems with XIE, but I haven't
been able to reproduce that bug with my setup.

This stack trace is from a debug build I built off of the CVS tree,
pulled around 4PM Pacific time on April 5 (I'm currently using the
2.4.3-ac3 kernel):

#0  0x40691131 in __kill () from /lib/libc.so.6
#1  0x4062c1ca in raise (sig=6) at signals.c:65
#2  0x40692518 in abort () at ../sysdeps/generic/abort.c:88
#3  0x405dfcee in PR_Assert (s=0x4060cf70 "PT_TRYLOCK_BUSY == rv", 
    file=0x4060cca0 "ptsynch.c", ln=487) at prlog.c:477
#4  0x405f9bc7 in PR_EnterMonitor (mon=0x808c188) at ptsynch.c:487
#5  0x4015f3c7 in free (ptr=0x808c188) at nsTraceMalloc.c:1379
#6  0x405e6137 in PR_Free (ptr=0x808c188) at prmem.c:66
#7  0x405f9a54 in PR_DestroyMonitor (mon=0x808c188) at ptsynch.c:450
#8  0x4015faa0 in NS_TraceMallocShutdown () at nsTraceMalloc.c:1558
#9  0x40693766 in exit (status=1) at exit.c:54
#10 0x40e9db42 in gdk_set_sm_client_id () from /usr/lib/libgdk-1.2.so.0
#11 0x40f357d4 in _XRead () from /usr/X11R6/lib/libX11.so.6
#12 0x40f3611a in _XReply () from /usr/X11R6/lib/libX11.so.6
#13 0x40f2c0cd in XQueryExtension () from /usr/X11R6/lib/libX11.so.6
#14 0x40f22811 in XInitExtension () from /usr/X11R6/lib/libX11.so.6
#15 0x415f8a2e in XieInitialize () from /usr/X11R6/lib/libXIE.so.6
#16 0x415b2238 in DrawScaledImageXIE (display=0x81081b8, aDest=0x434533b0, 
    aGC=0x434a6828, aSrc=0x436478a8, aSrcMask=0x0, aSrcWidth=1, aSrcHeight=1, 
    aSX=0, aSY=0, aSWidth=1, aSHeight=1, aDX=3, aDY=137, aDWidth=145, 
    aDHeight=1154) at XIE.c:148
#17 0x415bf8d0 in nsImageGTK::DrawScaled (this=0x436be568, 
    aContext=@0x436a1678, aSurface=0x42ebce60, aSX=0, aSY=0, aSWidth=1, 
    aSHeight=1, aDX=3, aDY=137, aDWidth=145, aDHeight=1154)
    at nsImageGTK.cpp:461
#18 0x415bf9dd in nsImageGTK::Draw (this=0x436be568, aContext=@0x436a1678, 
    aSurface=0x42ebce60, aSX=0, aSY=0, aSWidth=1, aSHeight=1, aDX=3, aDY=137, 
    aDWidth=145, aDHeight=1154) at nsImageGTK.cpp:505
#19 0x400481af in nsRenderingContextImpl::DrawScaledImage (this=0x436a1678, 
    aImage=0x43630a48, aSrcRect=0xbfffddb0, aDestRect=0xbfffdd80)
    at nsRenderingContextImpl.cpp:732
#20 0x4229424d in nsImageFrame::Paint (this=0x42eb5aa8, 
    aPresContext=0x43500b38, aRenderingContext=@0x436a1678, 
    aDirtyRect=@0xbfffde40, aWhichLayer=eFramePaintLayer_Overlay)
    at nsImageFrame.cpp:1061
#21 0x4226ffbe in nsContainerFrame::PaintChild (this=0x43519114, 
    aPresContext=0x43500b38, aRenderingContext=@0x436a1678, 
    aDirtyRect=@0xbfffe160, aFrame=0x42eb5aa8, 
    aWhichLayer=eFramePaintLayer_Overlay) at nsContainerFrame.cpp:206
#22 0x42269225 in nsBlockFrame::PaintChildren (this=0x43519114, 
    aPresContext=0x43500b38, aRenderingContext=@0x436a1678, 
    aDirtyRect=@0xbfffe160, aWhichLayer=eFramePaintLayer_Overlay)
    at nsBlockFrame.cpp:6626
#23 0x42268f20 in nsBlockFrame::Paint (this=0x43519114, 
    aPresContext=0x43500b38, aRenderingContext=@0x436a1678, 
    aDirtyRect=@0xbfffe160, aWhichLayer=eFramePaintLayer_Overlay)
    at nsBlockFrame.cpp:6503
#24 0x4226ffbe in nsContainerFrame::PaintChild (this=0x435190b8, 
    aPresContext=0x43500b38, aRenderingContext=@0x436a1678, 
    aDirtyRect=@0xbfffe358, aFrame=0x43519114, 
    aWhichLayer=eFramePaintLayer_Overlay) at nsContainerFrame.cpp:206
#25 0x4226fe3b in nsContainerFrame::PaintChildren (this=0x435190b8, 
    aPresContext=0x43500b38, aRenderingContext=@0x436a1678, 
    aDirtyRect=@0xbfffe358, aWhichLayer=eFramePaintLayer_Overlay)
    at nsContainerFrame.cpp:151
#26 0x4236cabe in nsTableCellFrame::Paint (this=0x435190b8, 
    aPresContext=0x43500b38, aRenderingContext=@0x436a1678, 
    aDirtyRect=@0xbfffe358, aWhichLayer=eFramePaintLayer_Overlay)
    at nsTableCellFrame.cpp:328
#27 0x4238237a in nsTableRowFrame::PaintChildren (this=0x43519070, 
    aPresContext=0x43500b38, aRenderingContext=@0x436a1678, 
    aDirtyRect=@0xbfffe47c, aWhichLayer=eFramePaintLayer_Overlay)
    at nsTableRowFrame.cpp:544
#28 0x423821ec in nsTableRowFrame::Paint (this=0x43519070, 
    aPresContext=0x43500b38, aRenderingContext=@0x436a1678, 
    aDirtyRect=@0xbfffe47c, aWhichLayer=eFramePaintLayer_Overlay)
    at nsTableRowFrame.cpp:499
#29 0x42384bba in nsTableRowGroupFrame::PaintChildren (this=0x43518c64, 
    aPresContext=0x43500b38, aRenderingContext=@0x436a1678, 
    aDirtyRect=@0xbfffe590, aWhichLayer=eFramePaintLayer_Overlay)
    at nsTableRowGroupFrame.cpp:274
#30 0x42384a54 in nsTableRowGroupFrame::Paint (this=0x43518c64, 
    aPresContext=0x43500b38, aRenderingContext=@0x436a1678, 
    aDirtyRect=@0xbfffe590, aWhichLayer=eFramePaintLayer_Overlay)
    at nsTableRowGroupFrame.cpp:230
#31 0x4226ffbe in nsContainerFrame::PaintChild (this=0x43518bfc, 
    aPresContext=0x43500b38, aRenderingContext=@0x436a1678, 
    aDirtyRect=@0xbfffe6e0, aFrame=0x43518c64, 
    aWhichLayer=eFramePaintLayer_Overlay) at nsContainerFrame.cpp:206
#32 0x4226fe3b in nsContainerFrame::PaintChildren (this=0x43518bfc, 
    aPresContext=0x43500b38, aRenderingContext=@0x436a1678, 
    aDirtyRect=@0xbfffe6e0, aWhichLayer=eFramePaintLayer_Overlay)
    at nsContainerFrame.cpp:151
#33 0x42374fa1 in nsTableFrame::Paint (this=0x43518bfc, 
    aPresContext=0x43500b38, aRenderingContext=@0x436a1678, 
    aDirtyRect=@0xbfffe6e0, aWhichLayer=eFramePaintLayer_Overlay)
    at nsTableFrame.cpp:1467
#34 0x4226ffbe in nsContainerFrame::PaintChild (this=0x43518bb0, 
    aPresContext=0x43500b38, aRenderingContext=@0x436a1678, 
    aDirtyRect=@0xbfffe7e0, aFrame=0x43518bfc, 
    aWhichLayer=eFramePaintLayer_Overlay) at nsContainerFrame.cpp:206
#35 0x4237d5b1 in nsTableOuterFrame::Paint (this=0x43518bb0, 
    aPresContext=0x43500b38, aRenderingContext=@0x436a1678, 
    aDirtyRect=@0xbfffe7e0, aWhichLayer=eFramePaintLayer_Overlay)
    at nsTableOuterFrame.cpp:369
#36 0x4226ffbe in nsContainerFrame::PaintChild (this=0x43518aec, 
    aPresContext=0x43500b38, aRenderingContext=@0x436a1678, 
    aDirtyRect=@0xbfffec08, aFrame=0x43518bb0, 
    aWhichLayer=eFramePaintLayer_Overlay) at nsContainerFrame.cpp:206
#37 0x42269225 in nsBlockFrame::PaintChildren (this=0x43518aec, 
    aPresContext=0x43500b38, aRenderingContext=@0x436a1678, 
    aDirtyRect=@0xbfffec08, aWhichLayer=eFramePaintLayer_Overlay)
    at nsBlockFrame.cpp:6626
#38 0x42268f20 in nsBlockFrame::Paint (this=0x43518aec, 
    aPresContext=0x43500b38, aRenderingContext=@0x436a1678, 
    aDirtyRect=@0xbfffec08, aWhichLayer=eFramePaintLayer_Overlay)
    at nsBlockFrame.cpp:6503
#39 0x422bf691 in PresShell::Paint (this=0x43625168, aView=0x4359b1d0, 
    aRenderingContext=@0x436a1678, aDirtyRect=@0xbfffec08)
    at nsPresShell.cpp:4859
#40 0x425e7f6e in nsView::Paint (this=0x4359b1d0, rc=@0x436a1678, 
    rect=@0xbfffec08, aPaintFlags=128, aResult=@0xbfffec20) at nsView.cpp:275
#41 0x425f2f32 in nsViewManager::RenderDisplayListElement (this=0x43612340, 
    element=0x430bfcc8, aRC=@0x436a1678) at nsViewManager.cpp:1392
#42 0x425f2c51 in nsViewManager::RenderViews (this=0x43612340, 
    aRootView=0x435197d8, aRC=@0x436a1678, aRect=@0xbfffed88, 
    aResult=@0xbfffeda0) at nsViewManager.cpp:1316
#43 0x425f1862 in nsViewManager::Refresh (this=0x43612340, aView=0x435197d8, 
    aContext=0x436a1678, rect=0xbfffee38, aUpdateFlags=1)
    at nsViewManager.cpp:883
#44 0x425f4517 in nsViewManager::DispatchEvent (this=0x43612340, 
    aEvent=0xbfffefb0, aStatus=0xbfffee94) at nsViewManager.cpp:1905
#45 0x425e77cd in HandleEvent (aEvent=0xbfffefb0) at nsView.cpp:67
#46 0x40cea95b in nsWidget::DispatchEvent (this=0x43519860, aEvent=0xbfffefb0, 
    aStatus=@0xbfffef54) at nsWidget.cpp:1471
#47 0x40cea553 in nsWidget::DispatchWindowEvent (this=0x43519860, 
    event=0xbfffefb0) at nsWidget.cpp:1362
#48 0x40cf11a1 in nsWindow::DoPaint (this=0x43519860, aX=8, aY=539, aWidth=89, 
    aHeight=31, aClipRegion=0x435199d0) at nsWindow.cpp:705
#49 0x40cf1373 in nsWindow::Update (this=0x43519860) at nsWindow.cpp:741
#50 0x40cf16e1 in nsWindow::Update (this=0x43500c68) at nsWindow.cpp:775
#51 0x40cf0ee2 in nsWindow::UpdateIdle (data=0x0) at nsWindow.cpp:617
#52 0x40edd97b in g_idle_dispatch () from /usr/lib/libglib-1.2.so.0
#53 0x40edc847 in g_main_dispatch () from /usr/lib/libglib-1.2.so.0
#54 0x40edcec1 in g_main_iterate () from /usr/lib/libglib-1.2.so.0
#55 0x40edd08c in g_main_run () from /usr/lib/libglib-1.2.so.0
This stack trace is from a debug build I built off of the CVS tree,
pulled around 4PM Pacific time on April 5 (I'm currently using the
2.4.3-ac3 kernel):

Comment 8

[av (gone)]

From the stack trace I cannot see how plugin module is involved here. Shouldn't 
we change the component to ImageLib?

Comment 9

[Matthew Cline]

The crash doesn't happen unless the plugger plugin tries to load a MIDI
sound file, neither of which has anything to do with imagelib; plugger
must be causing some sort of problem that cascades into imagelib, where
the crash happens.  Of course, the plug-in problem might be tickling
an already existing imagelib bug, in which case this is actually two
bugs rather than one.

Comment 10

[Matthew Cline]

Crash happens with both 3.2 and 3.3 versions of plugger; I haven't tested
any other versions of it.

Comment 11

[Chris Hiner]

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

Comment 12

[timeless]

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

Comment 13

[serge (gone)]

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

Comment 14

[Knut J]

It Still crash with Mozilla 0.92 when trying to chance to another media file. It
does not crash when loading a midi,but when I am trying to load another midi file.

Comment 15

[Knut J]

crash data

Playmidi 2.4 Copyright (C) 1994-1997 Nathan I. Laredo, AWE32 by Takashi Iwai
This is free software with ABSOLUTELY NO WARRANTY.
For details please see the file COPYING.
Gdk-ERROR **: BadWindow (invalid Window parameter)
  serial 21580 error_code 3 request_code 4 minor_code 0
Gdk-ERROR **: BadWindow (invalid Window parameter)
  serial 21581 error_code 3 request_code 4 minor_code 0

Comment 16

[Knut J]

talkback incident TB32371295E

Comment 17

[Knut J]

plugger 3.3-3.i386.rpm solve this problem, it can play midi without crashing
mozilla. ftp://people.redhat.com/than/

Comment 18

[David Shochat]

That doesn't work for me using RedHat 7.1, and configured to use timidity.
There is now no crash, but the music does not play. The same plugin (and same
config file) does play music using Netscape Communicator 4.77.
My pluggerrc:

audio/midi: midi,mid: MIDI audio file
audio/x-midi: midi,mid: MIDI audio file
	many: timidity -s 44100 -a -idqq $file > /dev/null 2>&1

Comment 19

[Knut J]

This is mine pluggerrc with plugger-3.3-3.i386.rpm. It works with Mozilla-0.9.2
wihtout crashing it. 

audio/mid: midi,mid: MIDI audio file
audio/x-mid: midi,mid: MIDI audio file
audio/midi: midi,mid: MIDI audio file
audio/x-midi: midi,mid: MIDI audio file
	exits : timidity "$file"

Comment 20

[David Shochat]

Tried that and it still doesn't work. Still no crash, but no music.
That version does work fine in Communicator 4.77 (although with subprocess
diag windows entering and leaving the page). My test URL is:
http://www4.justnet.ne.jp/~hama_cho/animemidi/kalocsa_e.html

Comment 21

[Matthew Cline]

With plugger 3.3-3, timidity 0.2, and Mozilla 2001062721, I still get
crashes, unless I run it under gdb, in which case it doesn't crash,
but doesn't get any sound.

Comment 22

[Matthew Cline]

Alright, I've tracked down part of the problem, which is that
when NPP_StreamAsFile() is called in plugger, the number of repeates
given (instance->pdate->repeats) is 0, so plugger never launches timidity.
Now, why not forking and execing timidity would causes Mozilla to get
a PIPE signal while in the X11 library, I have no clue; the fact that
this happens probably means that there is a bug somewhere else in plugger,
or in the Mozilla plugin code.  However, I am *sure* that not running
timidity is the proximate cause; fidling with the plugger code to force
repeats to be at least 1 makes everything work OK.

Shouldn't someone pull in plugger's author, Fredrik Hübinette,
<[e-mail]>, on this and get his help?

Comment 23

[Knut J]

I am not using timidity but playmidi with emu10k1 hardware wavetable

Comment 24

[Matthew Cline]

Here's what's happening with the two different ways Mozilla can go
(crashing and not crashing).  For non-crashing:

1) NPP_StreamAsFile() is called.
2) Plugger forks off a copy of Mozilla.
3) In the parent process, control returns from plugger to Mozilla.
4) In the child process, the midi-player is exec()ed.
5) The midi-player process exits.

For crashing:

1) NPP_StreamAsFile() is called.
2) Plugger forks off a copy of Mozilla.
3) In the parent process, control returns from plugger to Mozilla.
4) Since there's no exec, the child Mozilla process exits.
5) The exit handlers registered with atexit() are called by the
   child process.

It's the exit handlers that are causing the problem.  The child
Mozilla process is doing things with it's inherited file descriptors
that are having an affect on the parent process; probably the child
process is shutting down the X server connection of the parent
process, so the next time the parent process tries to do something
with X, it gets SIGPIPE.

There's two ways to look at this.  One is that plugins and/or
extensions/modules that fork but don't exec are broken, and we're not
going to do anything about it.  The other way to look at it is that we
want to protect against poorly coded plugins/extensions/modules.  To
go the second way, we could use pthread_atfork() to install a function
that will be called in the child process just before fork() returns;
this handler function would set some global data which says "Hey, I'm
a child process", and the atexit() handlers would check this and
behave accordingly.

If we want to do the second way of doing things, then I'll file a
separate bug for it.

Comment 25

[serge (gone)]

Matthew, you are right, exit() from child process causes this problem,
but I'm afraid I do not understand your proposal:) There are several
atexit()/on_exit()
registered functions which should be called in the reverse order of their
registration...,
how we can behave accordingly,  let say for gdk_exit_func()
which is atexit registered handler  and it calls XCloseDisplay (gdk_display)?
I think it's not a good idea at all to use exit() from child process in plugin's
code, use _exit()  instead.
I've posted diff for plugerr3.3  with _exit() as well as a binary fro testing in
bug 85542.
I've emailed to [e-mail] asking his opinion,
but hear nothing from him so far:(

Comment 26

[Knut J]

IN redhat rpm _exit is used instead of exit and pluggerrc is heavly modify.

Comment 27

[serge (gone)]

I'm checking out
ftp://people.redhat.com/than/plugger-3.3-3.src.rpm
...
grep -n "exit(" plugger.c
220:  exit(0);
306:      if(pid==-1) exit(10);
324:
exit(EX_UNAVAILABLE);
331:
if(!WIFEXITED(status)) exit(10);
333:
  exit(WEXITSTATUS(status));
352:      exit(EX_UNAVAILABLE);
355:  exit(0);
1195:
  _exit(0);
1279:
  exit(EX_UNAVAILABLE);

Is there another location of plugger src rpm?

Comment 28

[Knut J]

No it going to be relased wiht next Rawhide release date. Se bugzilla at
bugzilla.redhat.com. 

Comment 29

[serge (gone)]

all right, here is url http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=46767

Comment 30

[David Shochat]

I think there are two cases which should not be confused. 
(1) Explicit MIDI file link
(2) A MIDI file as the src attribute of an <embed> tag (i.e. background music).

Case I works fine with the version of plugger-3.3-3 posted by Knut. But then,
there is no need to use plugger in this case since you can simply install
timidity (or I suppose playmidi) as a helper app. This is actually a nicer
solution for this case since the page with the link remains in the window.
The links on http://members.tripod.com/knutjorgen/mid/ are of this type.

Case II I believe requires that a plugin be used. This no longer crashes with
this version of plugger, but it does not work for me using RedHat 7.1 and
mozilla 0.9.2 in the sense that no music is played. If I do a ps after
attempting such a page, I see a new <defunct> timidity process. Thus no music.
The two links marked "[with MIDI]", on
http://www4.justnet.ne.jp/~hama_cho/folkdance/gallery11/gallery11_e.htm
are of this type.

Comment 31

[Matthew Cline]

I realized that there's an easier way to use pthread_atfork().
When it is called in the child process, add an exit handler that calls
_exit().  Since the handlers are called in reverse order, this will get
called first, and none of the other handlers will get called, since _exit()
bypasses all of that.  I made a simmilar patch to plugger, which I submitted
to plugger's author, and also added as an attachment to bug 85542.

Comment 32

[Greg Smith]

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

Comment 33

[Knut J]

Plugger 4.0 does not cause mozilla to crash. It works with Mozilla 0.9.6,
perhaps this bug should be set to resolved. use 
audio/mid: midi,mid: MIDI audio file
audio/x-mid: midi,mid: MIDI audio file
audio/midi: midi,mid: MIDI audio file
audio/x-midi: midi,mid: MIDI audio file
	exits : timidity "$file"

Comment 34

[Greg Smith]

With Mozilla 0.9.6 I returned to the URL,
http://www.treefort.org/~rgrogan/web/beau.htm, and rather than crash it invited
me to install the plug-in. 

This process never works with Mozilla which is a bug in itself, but I did follow
the directions for installing the Plugger 4.0 RPM for linux (as root). I quit
Mozilla and restarted it and went to the "plugger Testing Grounds
(http://fredrik.hubbe.net/plugger/test.html). As far as I could tell Plugger was
not installed. Returning to the http://www.treefort.org/~rgrogan/web/beau.htm
URL confirmed this by popping up the window to install the plug-in again.

It is still pathetic that the process of installing plug-ins is so screwed up
and unclear, but at least it doesn't crash anymore. (Of course it might if
Plugger were really installed.)

Comment 35

[Knut J]

I have rebuilt plugger for redhat 7.2 it is at
http://members.tripod.com/knutjorgen/srpm/build.htm.
http://www.treefort.org/~rgrogan/web/beau.htm is still causing crash but the url
for this bugreport works fine.

Comment 36

[Greg Smith]

I was able to install the plugger 4.0 RPM for linux as root without any problem
(except that I received 8 messages saying "warning: user hubbe does not exist -
using root").

BTW - I am using RH 7.1. Is there something special I have to do in the
/usr/lib/mozilla/plugins directory in order to get this to work? I know that I
had to add symlinks in order to get Java and Flash to work. 

BTW - This is what I mean about the whole plug-in situation in Mozilla being a
bug. There were conflicting instructions in various places for how to get Java
to work and none of them are what I would call "user-friendly". There is no way
you can make any claim of user friendliness, if users are expected to know how
to track down esoteric instructions on the web and usenet for placing symlinks
(as root) into their plugins directory, just to get a plug-in to work.

Konqueror didn't have these problems. It just worked. Why can't Mozilla? I'm
sorry for being such a jerk about this. I think Galeon (and Mozilla on which it
is based) could be the best browser imaginable, if these piddling little
problems were fixed once and for all.

Comment 37

[Matthew Cline]

With plugger 4.0 and Mozilla 2001121408 I'm getting the same behavior as
Greg Smith: rather than crashing or not working, it asks me if I want to
download a plugin for type audio/midi, even though about:plugins shows that
Plugger is working and handles MIME type audio/midi; the same behavior happened
with Plugger 3.3 before I upgraded.  I compiled my own debugging and logging
build of plugger, and it doesn't seem to be doing anything at all.  I'll look
into this some more.

Comment 38

[Matthew Cline]

The reason that Plugger 4.0 isn't crashing is that it installs the config
file as /etc/pluggerrc-4.0, but it looks for /etc/pluggerrc when running;
a rename or softlink fixes that right up, and Mozilla crashes once more with
this error message:

Gdk-ERROR **: BadValue (integer parameter out of range for operation)
  serial 22 error_code 2 request_code 12 minor_code 0

Changing the bug's URL, as the old URL no longer has an embedded MIDI file.

Comment 39

[Knut J]

try this page http://members.tripod.com/knutjorgen/mid.htm. It also contain an
embed midi but it does not cause crash in mozilla 0.97. 

Comment 40

[Matthew Cline]

For Plugerr 4.0, the problem *isn't* being caused by plugger calling exit()
after having called fork(), but before calling exec(), like it was for
Plugger 3.x.  Now it's caused when NPP_SetWindow() in Plugger calls
XSync(); the stack trace is:

#0  exit (status=1) at exit.c:40
#1  0x4035e452 in gdk_x_error (display=0x8aa00d8, error=0xbfffccc0)
    at gdk.c:1095
#2  0x403fe663 in _XError () from /usr/X11R6/lib/libX11.so.6
#3  0x403fd29d in _XReply () from /usr/X11R6/lib/libX11.so.6
#4  0x403f89e8 in XSync () from /usr/X11R6/lib/libX11.so.6
#5  0x4138d97c in NPP_SetWindow (instance=0x89d45a8, window=0x88a4750)
    at plugger.c:1335
#6  0x4138de8b in Private_SetWindow (instance=0x89d45a8, window=0x88a4750)
    at /usr/local/PluginSDK30b5/common/npunix.c:194

If I comment out the call to XSync(), then plugger doesn't crash, but it
doesn't work: Mozilla asks me if I want to download a MIDI plugin.

Comment 41

[Sergey Lunegov]

I'm not sure but maybe the reason of this bug is the same
as for bug #108347. I applied patch for bug #108347 and browser
didn't crash. Browser crashed without patch. I used plugger of version 4.0.
Would somebody try to apply patch for bug #108347 and test the crashing ?

Comment 42

[Erik Hensema]

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

Comment 43

[Erik Hensema]

You may want to take a look at bug 102102, it's got some traces and bits of
potentially usefull info.

Comment 44

[Sergey Lunegov]

I couldn't reproduce crashing on URL specified in bug #102102
(with and without patch for #108347). 

Comment 45

[Marius Andreiana]

As I've mentioned in #102102, the original URL works in 0.9.7, but this one
crashes it:
http://www.ElectronicPostcards.com/cgi-bin/tgc/pickup.pl?ticket=1008436472.833

Comment 46

[Sergey Lunegov]

I tested browser behavior with URL mentioned in comment #45:
with applied patch for bug #108347 browser doesn't crash and 
without patch browser crashed. Can anybody apply patch for #108347
and confirm or disprove my results ?

Comment 47

[av (gone)]

--- Mass reassigning Unix bugs to serge ---

Comment 48

[serge (gone)]

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

Comment 49

[R.K.Aa.]

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

Comment 50

[rubydoo123]

moving to 1.1

Comment 51

[Matthias Versen [:Matti]]

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

Comment 52

[rubydoo123]

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

Comment 53

[Daniel Tonda Castillo]

I'm a regular non-engineer Linux user, and this is what I've experienced.
With netscape (pretty much any version) and a html document with an embedded
midi, plugger works fine, either by playing the embedded file or by clicking on
a link to a midi file. With galeon, plugger doesn't appear as a plugin.
With mozilla 1.0.0, clicking on a link to a midi file works, it downloads the
midi  file to /tmp/plugtmp and starts playing. 
When trying to play the file via the embed tag, it starts plugger which tries to
use timidity to play the file in /tmp/plugtmp, but there's no file there.
ps -A shows a defunct plugger.
?????

Comment 54

[rubydoo123]

reassign

Comment 55

[Marek Z. Jeziorek]

batch: adding topembed per Gecko2 document
http://rocknroll.mcom.com/users/marek/publish/Gecko/Gecko2Tasks.html

Comment 56

[saari (gone)]

->evang

Comment 57

[Michael Buckland]

Bulk adding topembed keyword.  Gecko/embedding needed.

Comment 58

[Michael Dunn]

Removing topembed kw: assigned to Evang

Comment 59

[Bob Clary [:bc] (inactive)]

-> plugins

Comment 60

[Bob Clary [:bc] (inactive)]

tech evang june 2003 reorg

Comment 61

[Bob Clary [:bc] (inactive)]

http://fredrik.hubbe.net/plugger.html

Comment 62

[Pascal Chevrel:pascalc (PTO until April 26)]

Could a Linux user test this page ? Is it still a problem ?

Comment 63

[Aleksander Adamowski]

With Plugger 5.1.3 and mozplugger-1.6 (a Mandrake RPM) all works fine.

This bug can be closed.

Comment 64

[Pascal Chevrel:pascalc (PTO until April 26)]

thanks, marking fixed.