244549 - crash [@ gtk_widget_style_get] (was: Roaming Profiles not publishing to server)

Status: RESOLVED WONTFIX

(Core :: Web Painting, defect)

Description

[Joe McCabe]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a2) Gecko/20040524
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a2) Gecko/20040524

Edit | Preferences | Roaming User
  X Enable remote profile storage
  HTTP / FTP
  Base URL ftp://ftp.machine.com/moz_roaming/
  Username qwe
    X Save password
  Password **********

My proxy server shows no FTP activity, and no files appear in the subdirctory
"moz_roaming" directory of user "qwe" on ftp.machine.com.

A relaunch of Mozilla throws a error about unable to retrieve an empty file,
then the startup proceeds using the local copies of the profile.

Reproducible: Always
Steps to Reproduce:

Comment 1

[Ben Bucksch (:BenB)]

I'll need a bit more info than 'it doesn't work'.

Do you see a crash during shutdown when it should upload? If so, in which function?
Which theme are you using? Classic? Can you try Modern?
I saw a crash in layout, but didn't have time to file it yet.

Comment 2

[Joe McCabe]

I realize that detail is light here. Unfortunately it's everything I have.

I had not noticed a crash at shutdown, but now that I look I see that cores were
being generated. Rather long stack trace will be attached to bug, but the top of
it looks like:

(gdb) where
#0  0x40752671 in kill () from /lib/i686/libc.so.6
#1  0x400d9afd in pthread_kill () from /lib/i686/libpthread.so.0
#2  0x400d9e9b in raise () from /lib/i686/libpthread.so.0
#3  0x416b437d in NSGetModule ()
   from /usr/local/mozilla/components/libprofile.so
#4  0x400dc67e in __pthread_sighandler () from /lib/i686/libpthread.so.0
#5  <signal handler called>
#6  0x402a370b in gtk_widget_style_get () from /usr/lib/libgtk-x11-2.0.so.0
#7  0x40f40689 in moz_gtk_get_scrollbar_metrics ()
   from /usr/local/mozilla/components/libgfx_gtk.so
#8  0x40f73ace in nsNativeThemeGTK::GetGtkWidgetAndState(unsigned char,
nsIFrame*, GtkThemeWidgetType&, GtkWidgetState*, int*) ()
   from /usr/local/mozilla/components/libgfx_gtk.so
#9  0x413179f4 in nsIBox::AddCSSMinSize(nsBoxLayoutState&, nsIBox*, nsSize&) ()
   from /usr/local/mozilla/components/libgklayout.so
#10 0x4131fab2 in nsContainerBox::CheckBoxOrder(nsBoxLayoutState&) ()
   from /usr/local/mozilla/components/libgklayout.so
#11 0x4131a4f4 in nsBoxFrame::IsInitialReflowForPrintPreview(nsBoxLayoutState&,
int&) () from /usr/local/mozilla/components/libgklayout.so
#12 0x4131fa29 in nsContainerBox::CheckBoxOrder(nsBoxLayoutState&) ()
   from /usr/local/mozilla/components/libgklayout.so

[...]

There are no accesses to the Proxy Server or to the remote FTP server.

Currently using the theme "Smoke." Will try "Modern."

Comment 3

[Joe McCabe]

Attachment: Stack trace showing crash when browser attempts to publish configs

Comment 4

[Joe McCabe]

Switching to theme "Modern" makes for different failure. Upon exit Moz throws a
dialog box with this text:

Transfer error with file "undefined": NS_ERROR_ILLEGAL_VALUE

Moz also throws this dialog on startup with the roaming profile.

Comment 5

[Ben Bucksch (:BenB)]

Thanks a lot. That's very useful. That's exactly the same stacktrace I saw.
Doesn't seem to be caused, only triggered, by roaming. Esp. given that the code
didn't change much since a year and it worked before. Over to layout.

Comment 6

[Ben Bucksch (:BenB)]

-> layout

Comment 7

[Joe McCabe]

Nifty.

One other update - After switching to "Modern" a crash still happens. The only
real difference seems to be that we're able to throw a dialog before we crash
out, unlike when I use the "Smoke" theme.

The stack of this crash looks much the same as the previous stack.

Comment 8

[Ben Bucksch (:BenB)]

You accidently stomped over my changes.

> After switching to "Modern" a crash still happens. The only
> real difference seems to be that we're able to throw a dialog before
> we crash out

Just what I saw. With Modern, the upload worked though, IIRC.

Comment 9

[Joe McCabe]

Hmm. A little poking got me the results you saw.

Will file new bugs.

Comment 10

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Can you track down a regression window?

Comment 11

[Joe McCabe]

Evidently the Roaming Profile checkin tickled this issue, but otherwise the
regression window is unknown.

Comment 12

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Hasn't the roaming profile code been in use for a while? 

Comment 13

[Joe McCabe]

The Roaming code was checked in 2004-05-24 09:55 and 2004-05-24 10:13.

Comment 14

[Ben Bucksch (:BenB)]

Not really in use. I wrote it beginning of 2003 and don't remember to have seen
the bug, waited for reviews, didn't use it myself. So, I can't tell you a better
regression window, I'd have to do a binary search myself.

Comment 15

[Robert O'Callahan (:roc) (email my personal email if necessary)]

That binary search would help a lot.

Comment 16

[Ben Bucksch (:BenB)]

Unfortunately, there are no binaries in the meantime. I'd have to cvs checkout
and build every one from source, this would take a whole day or so, and I don't
have time for that. All I have is a build based on Mozilla 1.4, and it doesn't
show the bug, but I guess that doesn't help much. Sorry.

Comment 17

[Ben Bucksch (:BenB)]

(roughly Mozilla 1.4.2 actually, in case that makes a difference.)

Comment 18

[Robert O'Callahan (:roc) (email my personal email if necessary)]

oh, I thought there was a roaming XPI. Oh well.

Comment 19

[Ben Bucksch (:BenB)]

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

Comment 20

[Ben Bucksch (:BenB)]

Pete Zha says in dup bug: "This is probably because we want to show a modal
dialog after gtk_main loop finished."

Comment 21

[Pete Zha]

Attachment: patch to fix it

We should set global variables' value to 0 after destroy them

Comment 22

[Ben Bucksch (:BenB)]

Thanks Pete, for fixing this! :-) Good catch.

I applied the patch, did the same for GTK1, removed a duplicated line. I'll
attach a patch. I no longer see a crash during the upload, using both Classic
and Modern, and roaming seems to work just fine.

However, I still do see a crash occasionally, using both Classic and Modern.
Stacktrace:

#7  <signal handler called>
#8  0x4026175b in gtk_widget_unref () from /opt/gnome/lib/libgtk-1.2.so.0
#9  0x411e969f in nsDragService::Observe (this=0x82a67f0, aSubject=0x0,
    aTopic=0x41f5c880 "quit-application", aData=0x0)
    at ../../../../mozilla/widget/src/gtk/nsDragService.cpp:134
#10 0x4078f6ae in nsObserverService::NotifyObservers (this=0x81ff3f0,
    aSubject=0x0, aTopic=0x41f5c880 "quit-application", someData=0x0)
    at ../../../mozilla/xpcom/ds/nsObserverService.cpp:208
#11 0x41f43606 in nsAppShellService::Quit (this=0x827f1d8, aFerocity=3)
    at ../../../../mozilla/xpfe/appshell/src/nsAppShellService.cpp:655
#12 0x41f32c9c in nsXULWindow::Destroy (this=0x8869730)
    at ../../../../mozilla/xpfe/appshell/src/nsXULWindow.cpp:543
#13 0x41f51840 in nsWebShellWindow::Destroy (this=0x8869730)
    at ../../../../mozilla/xpfe/appshell/src/nsWebShellWindow.cpp:1651
#14 0x41f28b6a in nsChromeTreeOwner::Destroy (this=0x85901b0)
    at ../../../../mozilla/xpfe/appshell/src/nsChromeTreeOwner.cpp:345
#15 0x4196915b in GlobalWindowImpl::ReallyCloseWindow (this=0x8826f40)
    at ../../../../mozilla/dom/src/base/nsGlobalWindow.cpp:3582
#16 0x4196cede in GlobalWindowImpl::CloseWindow (aWindow=0x8826f44)
    at ../../../../mozilla/dom/src/base/nsGlobalWindow.cpp:4640
#17 0x41957dc9 in nsJSContext::ScriptEvaluated (this=0x84ceed0, aTerminated=1)
    at ../../../../mozilla/dom/src/base/nsJSEnvironment.cpp:1780
#18 0x41956f2d in nsJSContext::CallEventHandler (this=0x84ceed0,
    aTarget=0x83007d0, aHandler=0x848ff20, argc=1, argv=0x83cd030,
    rval=0xbfffe2d8) at ../../../../mozilla/dom/src/base/nsJSEnvironment.cpp:1266
#19 0x4196dd53 in GlobalWindowImpl::RunTimeout (this=0x8826f40,
    aTimeout=0x83ccfe8)
    at ../../../../mozilla/dom/src/base/nsGlobalWindow.cpp:4977
#20 0x4196e87b in GlobalWindowImpl::TimerCallback (aTimer=0x83cd080,
    aClosure=0x83ccfe8)
    at ../../../../mozilla/dom/src/base/nsGlobalWindow.cpp:5338
[...]

Comment 23

[Ben Bucksch (:BenB)]

Attachment: Fix, v2. Incl. GTK1

Comment 24

[Ben Bucksch (:BenB)]

Compare stack in bug 244564 with last stack.

Comment 25

[Christopher Aillon (sabbatical, not receiving bugmail)]

Comment on attachment 149687 [details] [diff] [review]
Fix, v2. Incl. GTK1

r=me if you assign NULL instead of 0.

Comment 26

[Luke Reeves]

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

Comment 27

[Luke Reeves]

I still occasionally get a crash.  When I use roaming with a local FTP daemon,
it works.  When I setup a remote server for my roaming profile, I get a segfault:

#0  0x4082452c in nanosleep () from /lib/tls/libc.so.6
#1  0x40824368 in sleep () from /lib/tls/libc.so.6
#2  0x0806c69d in ah_crap_handler (signum=11) at nsSigHandlers.cpp:133
#3  0x42b48460 in nsProfileLock::FatalSignalHandler (signo=11)
    at nsProfileLock.cpp:208
#4  <signal handler called>
#5  0x4053363c in g_type_check_instance_cast ()
   from /usr/lib/libgobject-2.0.so.0
#6  0x431af115 in setup_widget_prototype (widget=0x86be8d0)
    at gtk2drawing.c:109
#7  0x431af211 in ensure_radiobutton_widget () at gtk2drawing.c:139
#8  0x431afcac in moz_gtk_radio_get_metrics (indicator_size=0xbfffa674, 
    indicator_spacing=0xbfffa670) at gtk2drawing.c:447
...

I'll attach the full trace.

Comment 28

[Luke Reeves]

Attachment: Stack trace (after patch applied)

Comment 29

[Christopher Blizzard (:blizzard)]

Comment on attachment 149687 [details] [diff] [review]
Fix, v2. Incl. GTK1

I'll bet we're still going to have problems in other places.

Comment 30

[Pete Zha]

Attachment: patch which need advice

If we don't destroy, it will not happen... But I'm not sure this is acceptable.
Please advise.

And some problem in DragService should be fixed since the mHiddenWidget should
be set to NULL to make sure it will not crash when we come back to use it
again.

Anyway, the root cause is the roaming dialog popup after graphics toolkit
shutdown. And I don't have a good idea about how to improve it. Because it has
to be popup when after browser write profile. Otherwise it will not upload
correct profile to server...

Comment 31

[timeless]

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

Comment 32

[Christopher Aillon (sabbatical, not receiving bugmail)]

Comment on attachment 161934 [details] [diff] [review]
patch which need advice

Not sure I like this approach, and anyway, we need to remove, not comment out
lines.	The dragservice change looks good though.  Out of curiosity, why has
the first patch not landed?  It should definitely help, if not completely
resolve the problem...

Comment 33

[Nian Liu(n/a in a long time)]

file/copy works fine with both classic and modern theme
ftp falied in either classic or modern thems with different core stack

Comment 34

[Nian Liu(n/a in a long time)]

test based on GTK2, co on Fri Feb 4 11:36:26 CST 2005

Comment 35

[Nian Liu(n/a in a long time)]

We can use observer to improve moz_gtk_shutdown. Once roaming download, we
notity nsNativeThemeGTK an upload of roaming will happen when quit, then
nsNativeThemeGTK set a sign, let's see mWaitingForRoamDone to true. When
"quit-application" is received, nsNativeThemeGTK will first judge whether sign
is set true. If not, do as before; If yes, wait for roaming upload done, then do
as before.

Comment 36

[Nian Liu(n/a in a long time)]

Christopher and Ben, can either of you check in Pete's patch(pls. also add
nsDragService part)? I myself, unfortunelly, don't have the authority to check
in in community

Comment 37

[Christopher Aillon (sabbatical, not receiving bugmail)]

Comment on attachment 149687 [details] [diff] [review]
Fix, v2. Incl. GTK1

I just checked this in, with s/0/NULL/ and also made sure to NULL out
gCheckMenuItemWidget which got added since the patch was created.

Comment 38

[Nian Liu(n/a in a long time)]

en, test on HTTP met same core stack as comment#2

Comment 39

[Christopher Blizzard (:blizzard)]

Comment on attachment 161934 [details] [diff] [review]
patch which need advice

Maybe catching a "real" shutdown signal so you know when to release those
widgets?

Comment 40

[Christian :Biesinger (don't email me, ping me on IRC)]

did bug 257196 fix this?

Comment 41

[Nian Liu(n/a in a long time)]

(In reply to comment #40)
> did bug 257196 fix this?

with latest seamonkey trunk, roaming itself doesn't work with error message
"some silly ok handler"

Comment 42

[Sylvestre Ledru [:Sylvestre]]

Closing because no crash reported since 12 weeks.