879373 - crash in IA__gdk_window_process_all_updates [@ libgdk-x11-2.0.so.0.2400.18@0x3c5af ] when file save dialog opens

Status: RESOLVED WORKSFORME

(Core :: Widget: Gtk, defect)

Description

[Christian Riechers]

User Agent: Mozilla/5.0 (X11; Linux i686; rv:21.0) Gecko/20100101 Firefox/21.0 (Beta/Release)
Build ID: 20130511120803

Steps to reproduce:

Opened a PDF from a banking web site with the internal PDF viewer, and attempted to save it to disk.
OS is Linux openSUSE 12.3.



Actual results:

FF crashed. This happened multiple times with different PDFs, all from the same site.
ID: bp-7f4d4c45-6d8a-41c8-962b-b74472130603
Signature: libgdk-x11-2.0.so.0.2400.18@0x3c5af
The crash happened with both, FF 21.0, and 22.0b3.


Expected results:

No crash.

Comment 1

[Piotr]

I am a victim of this bug too. I have stock openSUSE 12.3 64 bit with xfce with dependencies for 32 bit xulrunner from standard opensuse repository. And I have beta release of Mozilla Firefox 32 bit from mozilla page. I don't have in Firefox browser any plugins, but i have some addons.

My installed packages:
http://pastebin.com/Kix39uJu

There are crash reports from my PC:
https://crash-stats.mozilla.com/report/index/bp-2f59e59c-fd92-47ab-a272-3aa102130616
https://crash-stats.mozilla.com/report/index/bp-dae0bdbf-880a-49ad-b1f7-df2502130606
https://crash-stats.mozilla.com/report/index/bp-99e2e6a0-d4d8-4afa-a85b-34c4c2130604

In one of them i wrote how to reproduce a bug:
"I reproduced the crash again (previously said i was downloading linux archive, it was scilab archive http://www.scilab.org/download/5.4.1/scilab-5.4.1.bin.linux-x86_64.tar.gz) I cleared history and other things. I went on google page. I writed scilab. I went to download page for scilab. I clicked on link to download 64 bit version. I have opensuse 12.3 64 bit system, xfce 4.10.0. Fully updated. default distro kernel, not patched with anything: Linux  3.7.10-1.4-desktop"

Comment 2

[Piotr]

Attachment: installed packages in my opensuse

My installed packages in opensuse gnu/linux system.

Comment 3

[Piotr]

And this is my user agent, i don't think it is important:
Your user agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:22.0) Gecko/20100101 Firefox/22.0
Other HTTP headers
Connection: keep-alive
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding: gzip, deflate
Accept-Language: pl,en-us;q=0.7,en;q=0.3
Host: duckduckgo.com
Referer: https://duckduckgo.com/?kl=pl-pl&kad=pl_PL&kp=-1&kn=1
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:22.0) Gecko/20100101 Firefox/22.0
Content-Length:
Content-Type:
DNT: 1

Comment 4

[Karl Tomlinson (:karlt)]

Can someone who can reproduce install debug symbols for glib and gtk, please, attach gdb to the process, and get a stack trace when it crashes, please?

The gdb command "handle SIGPIPE nostop" may be useful.

Comment 5

[Piotr]

Attachment: amateur backtrace

Sorry, if it is not usefull. I don't have much time to spend on learning gdb. I installed debug symbols for all packages with:
1. gtk and debug in name of packege
2. glib and debug in name of package

Comment 6

[Piotr]

(In reply to lampshade from comment #5)
> Created attachment 763412 [details]
> amateur backtrace
> 
> Sorry, if it is not usefull. I don't have much time to spend on learning
> gdb. I installed debug symbols for all packages with:
> 1. gtk and debug in name of packege
> 2. glib and debug in name of package

And it is the crash report from this reproduction of bug: https://crash-stats.mozilla.com/report/index/bp-cb4b564a-337a-46b8-bae5-6f5532130617

Comment 7

[Karl Tomlinson (:karlt)]

That's perfect thanks.

It looks the same as a one-off report in 2011 - bug 649335.

I don't know what is going wrong there.  Perhaps memory corruption or something using GDK from the wrong thread, but a little strange to get crashes consistently in the same place if that is the reason.

I would try safe mode and/or disabling plugins.

Comment 8

[Piotr]

Attachment: another amateur backtrace

I don't know how to help. I have seen on ubuntu wiki page more commands to gdb (info registers, x/16i $pc) and I can only attach another backtrace with it. Bug not always is reproductable, I several times cleared a history (I don't know it is nesecary) and downloaded warious files (pdfs and tar archives) and it happens once in five attempts. It happens when window to choose where to save file displays.
This time it is this crash report: https://crash-stats.mozilla.com/report/index/bp-a05da4ed-7190-4daf-8cb8-e14ab2130617

Comment 9

[Christian Riechers]

I can reproduce the crash with one particular PDF. It also happens in safe mode.

Comment 10

[Piotr]

Attachment: Another unnesecary backtrace :P

I can reproduce a bug not only with pdf files, so i don't think it is related to specific files.
I am learning how to debug:P I paste new debug maked on system with more debug-info but still it isn't have fully symbolic stack trace debug. For more I must download and install official firefox symbols from mozilla server. I will do that when I will have some free time.

Comment 11

[Piotr]

Attachment: somemoresymbols backtrace

I downloaded script from https:/ /developer.mozilla.org/en-US/docs/Using_the_Mozilla_symbol_server and this downloaded for my debug symbols for firefox. But not everything was ok, some symbols didn't fitted in well. But this backtrace have more informations i think.
This reproduction is reported on: https://crash-stats.mozilla.com/report/index/bp-6deb6ea4-e974-42e9-84b1-c41c22130617

It is my last backtrace i promise.

Comment 12

[Scoobidiver (away)]

Adding a close crash signature with the same time of STR.
It's #3 top browser crasher in 21.0 on Linux.

More reports at:
https://crash-stats.mozilla.com/report/list?signature=libgdk-x11-2.0.so.0.2400.18%400x3c6ba
https://crash-stats.mozilla.com/report/list?signature=libgdk-x11-2.0.so.0.2400.18%400x3c5af

Comment 13

[Karl Tomlinson (:karlt)]

The comment on one of the Fedora (3c6ba) crash reports mentions "Fedora's Dolphin file manager", and most of the Fedora reports that I saw had oxygen-gtk loaded.

I don't see this module in the openSUSE crash reports, but wonder whether there is something similar.  Does the file save dialog look like a GTK dialog or one made to look like a KDE dialog?

Does moving ~/.gtkrc-2.0 change the GTK theme used (on application restart) and does the same crash still happen?

Comment 14

[Karl Tomlinson (:karlt)]

KDE I think also sets GTK2_RC_FILES to add other config files overriding ~/.gtkrc-2.0, so check that too if set.

Comment 15

[Christian Riechers]

Using Gnome 3.6 here. Dolphin isn't involved in any way. There is no ~/.gtkrc-2.0 either. The closest to that would possibly be /etc/gtk-2.0/gtkrc or /usr/share/themes/Adwaita/gtk-2.0/gtkrc. Again, this is openSUSE 12.3.

Comment 16

[Karl Tomlinson (:karlt)]

It's possible to test the other thread hypothesis by setting breakpoints as follows:

(gdb) break gdk_window_process_all_updates
Function "gdk_window_process_all_updates" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y

Breakpoint 1 (gdk_window_process_all_updates) pending.
(gdb) break gdk_window_add_update_window
Function "gdk_window_add_update_window" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y

Breakpoint 2 (gdk_window_add_update_window) pending.
(gdb) break gdk_window_remove_update_window
Function "gdk_window_remove_update_window" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y

Breakpoint 3 (gdk_window_remove_update_window) pending.
(gdb) run

Breakpoint 2, gdk_window_add_update_window (window=0x49d6c0)
    at gdkwindow.c:5242
5242	gdkwindow.c: No such file or directory.
(gdb) p $_thread
$1 = 1
(gdb) condition 2 $_thread != 1
(gdb) c
Continuing.

Breakpoint 1, IA__gdk_window_process_all_updates () at gdkwindow.c:5658
5658	in gdkwindow.c
(gdb) p $_thread
$2 = 1
(gdb) condition 1 $_thread != 1
(gdb) c
Continuing.
Breakpoint 3, gdk_window_remove_update_window (window=0x49d6c0)
    at gdkwindow.c:5315
5315	in gdkwindow.c
(gdb) condition 3 $_thread != 1
(gdb) c
Continuing.

If the program does not stop at any more breakpoints, then the functions are used on the correct threads.  If it does stop, then please attach the backtrace at that breakpoint.

Some of those functions may be inlined in GDK, so I'm not sure whether this will catch *all* entry points.

Comment 17

[Piotr]

Attachment: Debug with breakpoints

Debug logs from debugging with breakpoints. I still don't know if I do it right, so check it yourself. In my opinion crash is happening in first thread (or called by first thread)... But check it yourself.
Reproduction of this bug took me 1 hour (Yes, I am very patient in some cases), so there are many unuseful information about creating and exiting threads. Sorry.

Comment 18

[Piotr]

Attachment: /etc/gtk-2.0/gtkrc

This is /etc/gtk-2.0/gtkrc. I don't have gtkrc in home directory.

Comment 19

[Piotr]

Attachment: /etc/gtk-2.0/gtk.immodules

/etc/gtk-2.0/gtk.immodules

Comment 20

[Piotr]

Attachment: /etc/gtk-2.0/gtk64.immodules

/etc/gtk-2.0/gtk64.immodules

Comment 21

[Piotr]

Attachment: /usr/share/themes/Adwaita/gtk-2.0/gtkrc

/usr/share/themes/Adwaita/gtk-2.0/gtkrc

Comment 22

[Piotr]

https://crash-stats.mozilla.com/report/index/bp-c4dea383-c13c-4e99-a557-7c01b2130622
This is my crash report for reproduction of bug for uploaded backtrace with breakpoints.

Comment 23

[Piotr]

Attachment: another backtrace with breakpoints

Firefox starts from zero and from root account. And there is the same, crash still is triggered by first thread.

Comment 24

[Karl Tomlinson (:karlt)]

Thanks, again.  That seems to exclude those methods being used from the wrong thread.

Comment 25

[Piotr]

I will have some free time to learn and help since July 3. Does Valgrind logs should be usefull? I found out that I should compile firefox with special flags, but I am going to do it if it will be helpfully. If not, what other action can I take to provide usefull informations?

Comment 26

[Karl Tomlinson (:karlt)]

Valgrind can be useful, but it is only useful if it finds something, and we don't know unless we try.

If you disble the jit in chrome and content - seach for jit in about:config - then you may be OK with a regular build.  There may be some false positives due to a special memory allocator, but worth a try.

Comment 27

[Karl Tomlinson (:karlt)]

The crash reports seem to be with GTK+ 2.24.18.  I would try 2.24.17 to see whether that has the same problem.

Comment 28

[Scoobidiver (away)]

There are 20 crashes in 22.0.

Comment 29

[Piotr]

I am going to try with other version of GTK+ soon. Meanwhile I wanted to do memory error detection by valgrind's memcheck. And I think I am doing something wrong. I builded Firefox from source but:
1. I wanted to build stable (22.0) release, but I builded 25a1 release.
2. The binary when is not attached to gdb or valgrind is noticeably slower. When I started it by: G_SLICE=always-malloc G_DEBUG=gc-friendly  valgrind -v --tool=memcheck --leak-check=full --num-callers=40 --smc-check=all-non-file  --log-file=valgrind_interia.log /home/lukasz/kompilacja/pierwsza/firefox/mozilla-central/ff-opt/dist/bin/firefox
it is opening normal page in I suppose 2 minutes... Reproducing a bug under these conditions if is possible, would/will (sorry for my English) take great ammount of time.

To download code: hg clone https://hg.mozilla.org/mozilla-central

My .mozconfig:
. $topsrcdir/browser/config/mozconfig
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/ff-opt
ac_add_options --disable-tests
ac_add_options --enable-optimize="-g -O0"
ac_add_options --disable-jemalloc
ac_add_options --enable-valgrind


and I runned: ./mach build

Comment 30

[Piotr]

Under this run I didn't reproduced this bug, because firefox was too slow to even try to reproduce a bug. Firefox wasn't able even to open a new tab in one minute... So probably the bug is still there in sources.
How can I speed up the binary and provide false-positive-free logs? How should look mozconfig?

Comment 31

[Piotr]

Attachment: log from valgrind's memcheck

valgrind version: valgrind-3.8.1 from openSUSE 12.3 repository
what am I doing wrong?

Comment 32

[Karl Tomlinson (:karlt)]

Removing "--leak-check=full" will give a much shorter log.

Replacing 'ac_add_options --enable-optimize="-g -O0"' with 'ac_add_options --enable-debug-symbols="-g"' will make things run a little faster.

Removing "--smc-check=all-non-file" and instead disabling jit as in comment 26 will make things run considerably faster.

But valgrind will still not be fast, and it probably won't be helpful if this is a reference counting bug.

Comment 33

[Karl Tomlinson (:karlt)]

As something different to try, I suggest building with
ac_add_options --disable-tests --enable-debug --enable-jemalloc --disable-valgrind

I'd expect this build to produce assertion messages similar to bug 887587
before crashing.

Running with NSPR_LOG_MODULES=Widget:5 and G_DEBUG=fatal-warnings in the
environment will produce some messages such as

631646016[1d64d40]: nsWindow [26c37e0]
631646016[1d64d40]:     mShell 21a1440 mContainer 218d840 mGdkWindow 1dc85a0 0x2a0009c

If you can catch a backtrace like the one in bug 887587 comment 0, then you can
compare the pointer value _object with the mGdkWindow messages printed
(1dc85a0 in the line above) to see whether this is a Gecko window that has be
released one too many times.

Comment 34

[Karl Tomlinson (:karlt)]

If you can build your own GTK, then I'd suggest trying to bisect the GTK revisions between 2.24.17 and 2.24.18 to find the one that triggered the crash.

Comment 35

[Federico]

This probably blocks bug 802825.

Comment 36

[Wayne Mery (:wsmwk)]

(In reply to Karl Tomlinson (ni?:karlt) from comment #34)
> If you can build your own GTK, then I'd suggest trying to bisect the GTK
> revisions between 2.24.17 and 2.24.18 to find the one that triggered the
> crash.

That said, Christian closed bug 889585 a long time ago. So is this and the other bugs WFM?
bug 887587
bug 649335 - no crash reports in 28 days https://crash-stats.mozilla.com/report/list?range_unit=days&range_value=28&signature=IA__gdk_window_process_all_updates#tab-reports

Comment 37

[Christian Riechers]

Meanwhile on GTK 2.24.28. There are no crashes anymore, so WFM.