Page 2 of 3

Re: PM4Linux and oxygen-gtk: a better solution

Posted: 2014-07-07, 11:29
by access2godzilla
Apparently, there are no code changes within PM and FF which would cause this conflict.

Comparing the release notes shows that the version closest to PM 24.1.0 is FF 24.1.0. Comparing the two source trees gives me this (with only those parts that could be of our interest):

Code: Select all

./python/psutil/build/lib.linux-x86_64-2.7/_psutil_linux.so
./python/psutil/build/lib.linux-x86_64-2.7/_psutil_posix.so
./python/psutil/build/temp.linux-x86_64-2.7/psutil/_psutil_linux.o
./python/psutil/build/temp.linux-x86_64-2.7/psutil/_psutil_posix.o
./python/psutil/_psutil_linux.so
./python/psutil/_psutil_posix.so
./gfx/2d/Blur.cpp
./gfx/cairo/libpixman/src/Makefile.in
./gfx/cairo/libpixman/src/pixman-fast-path.c
./gfx/thebes/gfxPlatform.cpp
./gfx/thebes/gfxWindowsPlatform.cpp
  • /gfx/* doesn't seem to have any changes that could possibly cause this bug. /python/psutil/*(posix|linux)* seem to be missing from the Pale Moon source tree.
  • The only strange thing I noticed that FF needed --disable-elf-hack to compile*; PM didn't. The makefiles/configure.* didn't show anything that could be related to this.u
    The copy of FF ESR I compiled didn't crash, OTOH PM did.
Any hints as to where should I look at now?
*: --disable-elf-hack doesn't fix these crashes for PM.

Re: PM4Linux and oxygen-gtk: a better solution

Posted: 2014-07-07, 12:59
by Antonius32
access2godzilla wrote:Comparing the release notes shows that the version closest to PM 24.1.0 is FF 24.1.0.
To get this straight:
  • The first version of Pale Moon that was released for Linux is version 24.2.0 24.2.2.
  • The last version of Pale Moon that was not released for Linux is version 24.1.0.
  • For testing purposes, you have just built version 24.1.0 for Linux, and it crashes when used together with oxygen-gtk.
  • Pale Moon v 24.1.0 was based on Firefox ESR v 24.1.0; the Linux version of Firefox ESR v 24.1.0 does not crash when used together with oxygen-gtk.
Correct?

Re: PM4Linux and oxygen-gtk: a better solution

Posted: 2014-07-07, 14:07
by access2godzilla
The first released version was 24.2.2; but anyway the PM source always contained Linux code, just that no one built it before. And you're right, Firefox ESR, even the ones that I built myself, doesn't crash (That eliminates the possibility that the toolchains were responsible.)

I'm really not sure where else the reason behind the crashes could be hiding; unfortunately without the help of Moonchild it would be diffcult to isolate the problem. After all, I am not well versed with the Mozilla codebase.
(It should be noted that that the bug is with oxygen-gtk; just that I'm attempting to do something to reduce its severity. A browser that crashes even before you do something with it doesn't leave people with a good impression. After all, Firefox doesn't do the same.)

Re: PM4Linux and oxygen-gtk: a better solution

Posted: 2014-07-07, 15:06
by Antonius32
access2godzilla wrote:(...) the PM source always contained Linux code, just that no one built it before. And you're right, Firefox ESR, even the ones that I built myself, doesn't crash (...)
So I assume then, that Firefox for Windows and Firefox for Linux are built from the exact same source code, just like PM4Linux is built from the same source code as Pale Moon for Windows?
access2godzilla wrote:A browser that crashes even before you do something with it doesn't leave people with a good impression. After all, Firefox doesn't do the same.
My thoughts exactly. I really think fixing this would benefit Pale Moon's overall reputation.
access2godzilla wrote:I'm really not sure where else the reason behind the crashes could be hiding; unfortunately without the help of Moonchild it would be diffcult to isolate the problem.
As you have ruled out the option of the build process being the cause for this, it must be a divergence from Firefox's source code that was decided at some point in time. I hope Moonchild can help narrow down the options, by pointing out the changes (compared to Firefox) that are likely to be related to this issue, and by letting you know the version numbers at which those changes were implemented. Then one by one, the versions preceding those that saw the implementation of such a change could be rebuilt for Linux, to pinpoint the change that's causing this GTK issue...

Of course, that's easier said than done; I wish there was more I could do to help!

Re: PM4Linux and oxygen-gtk: a better solution

Posted: 2014-07-07, 15:18
by Moonchild
Without knowing what exactly causes this issue, it's impossible to find a solution.
Since I am by far a Windows developer, I'll have to divert this question to the people who have offered to maintain the Linux port, which involves more than just building and publishing: primarily cyansmoker, also perhaps Nigaikaze, and access2godzilla (when you have time)

Re: PM4Linux and oxygen-gtk: a better solution

Posted: 2014-07-07, 20:15
by Antonius32
For what it's worth (you never know), here's the error that shows when Pale Moon crashes:

Code: Select all

###!!! ABORT: X_CreatePixmap: BadAlloc (insufficient resources for operation); 4 requests ago: file /root/Projects/palemoon/Pale-Moon/toolkit/xre/nsX11ErrorHandler.cpp, line 157
###!!! ABORT: X_CreatePixmap: BadAlloc (insufficient resources for operation); 4 requests ago: file /root/Projects/palemoon/Pale-Moon/toolkit/xre/nsX11ErrorHandler.cpp, line 157
Segmentation fault

Re: PM4Linux and oxygen-gtk: a better solution

Posted: 2014-07-07, 22:07
by Moonchild
Insufficient resources? Heh, that would mean you run out of VRAM, meaning, in turn, something has a horrible memory leak in that theme.

Re: PM4Linux and oxygen-gtk: a better solution

Posted: 2014-07-08, 00:33
by Antonius32
This may also be worth mentioning:
  • Pale Moon + oxygen-gtk + newly created profile => Pale Moon is shut down instantly when the user tries to open a drop-down menu.
  • Pale Moon + oxygen-gtk + profile with add-ons, a lightweight theme, and personal preferences => Pale Moon runs steadily, but the background for drop-down menus is transparant (or missing, I guess).
I suppose I could single out the add-on or setting that causes this disparity; just let me know if I should.

(If one of my add-ons "fixes" the crash problem by disabling a part of the oxygen-gtk theme that's responsible for drop-down menu backgrounds, then maybe this property could be copied and built into Pale Moon; the only thing left to do then, would be to have Pale Moon replace the missing backgrounds with something else.. Or am simplifying too much now?)

Re: PM4Linux and oxygen-gtk: a better solution

Posted: 2014-07-08, 04:29
by access2godzilla
This is the full list of files changed/added/removed in PM 24.1.0 compared to FF 24.1.0: http://pastebin.com/K3S83PiN
Which files cannot possibly be related with these crashes? My earlier attempt to prune the list failed horribly :(

Re: PM4Linux and oxygen-gtk: a better solution

Posted: 2014-07-08, 10:20
by Antonius32
@acces2godzilla: Did you read my previous post? Do you think my suggestion (finding out which add-on causes PM4Linux to not crash) may help get you headed in the right direction? (If not, I'm afraid I can't help you any further.)

Re: PM4Linux and oxygen-gtk: a better solution

Posted: 2014-07-08, 12:35
by Moonchild
I think another important question to ask would be: what is different in the way Mozilla builds linux browsers compared to how it is done for Pale Moon? Is there a different toolchain used? different compiler? different optimization/configure options that would cause this?

Re: PM4Linux and oxygen-gtk: a better solution

Posted: 2014-07-08, 13:54
by Antonius32
I think access2godzilla has ruled out that option already:
access2godzilla wrote:And you're right, Firefox ESR, even the ones that I built myself, doesn't crash (That eliminates the possibility that the toolchains were responsible.)

Re: PM4Linux and oxygen-gtk: a better solution

Posted: 2014-07-08, 19:36
by Moonchild
Antonius32 wrote:I think access2godzilla has ruled out that option already:
All right, so how about optimization/configure options in use?

Re: PM4Linux and oxygen-gtk: a better solution

Posted: 2014-07-09, 08:10
by access2godzilla
I tried making a debugging enabled, non-optimised build and that crashes too. As far as flags are concerned, I did need a --disable-elf-hack for Firefox but not for Pale Moon. Hence I also built a debug enabled, non-optimised build with --disable-elf-hack, but that didn't help.

Re: PM4Linux and oxygen-gtk: a better solution

Posted: 2014-07-09, 09:07
by Moonchild
Definitely a conundrum. I wish I could provide more insight, but there aren't any code changes that I know of that would possibly affect this - mainly because I still don't know what falls over in that specific theme...

Re: PM4Linux and oxygen-gtk: a better solution

Posted: 2014-07-09, 11:56
by access2godzilla
Moonchild wrote:but there aren't any code changes that I know of that would possibly affect this
My question is, what can I eliminate from the diff? Can I eliminate all js, css, html/xul files from it?
Moonchild wrote:I still don't know what falls over in that specific theme...
This is, strictly speaking, not our problem: this is just a horribly made theme that mucks about at a dangerously low level with every GTK program. I'm trying to just find out what Pale Moon does differently from Firefox that causes this.

Re: PM4Linux and oxygen-gtk: a better solution

Posted: 2014-07-09, 22:27
by Moonchild
access2godzilla wrote:My question is, what can I eliminate from the diff? Can I eliminate all js, css, html/xul files from it?
No, not necessarily. If it is as unstable at a low level as you say it is, then anything can set it off. Browser chrome is drawn in very much the same way as page content. It uses hardware acceleration when available, and as such uses textures and layers with different properties and drawing methods. A simple css effect or size can set it off if it hits a sore spot. Adding or removing a XUL visual element could, too. dynamically changing something with js can also cause errors. Different font rendering, blurring method, etc. all can contribute to the problem - it's like trying to find out what makes a bad video driver fall over, and it's best to simply not try to use it, at all.

Re: PM4Linux and oxygen-gtk: a better solution

Posted: 2014-07-10, 09:42
by access2godzilla
The above was also a request to see what could be eliminated from the diff. I don't think anything in /browser/branding/* or /browser/themes/* could cause crashes ;)

Re: PM4Linux and oxygen-gtk: a better solution

Posted: 2014-07-10, 10:13
by Moonchild
access2godzilla wrote:The above was also a request to see what could be eliminated from the diff. I don't think anything in /browser/branding/* or /browser/themes/* could cause crashes ;)
Actually, yes they can if the skinning back-end in the OS is very unstable, just using a different bitmap could already cause it... so themes and branding ARE just as much candidates for triggering a problem.

I can't help but wonder why it's made the default for a number of distros if it is known to cause crashes in many applications?

Re: PM4Linux and oxygen-gtk: a better solution

Posted: 2014-07-12, 16:13
by access2godzilla
Not really willing to scan through ~10000 lines to find where the problem is (not even considering the fact that I don't have the time these days). But I think branding and such can be eliminated because branding isn't being rendered when the browser menus are opened. Culling the list gives me this, and I still have to go over ~3000 lines:

Code: Select all

./browser/base/content/browser-feeds.js
./browser/base/content/aboutDialog.css
./browser/base/content/aboutDialog.xul
./browser/base/content/nsContextMenu.js
./browser/base/content/safeMode.js
./browser/base/content/safeMode.xul
./browser/base/content/browser-fullScreen.js
./browser/base/content/browser-plugins.js
./browser/base/content/browser-sets.inc
./browser/base/content/browser-tabPreviews.js
./browser/base/content/browser-tabPreviews.xml
./browser/base/content/browser.css
./browser/base/content/browser.js
./browser/base/content/browser.xul
./browser/base/content/tabbrowser.xml
./browser/base/content/test/browser_ctrlTab.js
./browser/base/content/test/browser_visibleTabs.js
./browser/base/content/web-panels.xul
./browser/base/content/browser-context.inc
./browser/base/content/browser-doctype.inc
./browser/base/jar.mn
./browser/components/about/AboutRedirector.cpp
./browser/components/build/nsModule.cpp
./browser/components/moz.build
./browser/components/nsBrowserGlue.js
./browser/components/preferences/advanced.xul
./browser/components/preferences/tabs.xul
./browser/components/preferences/content.xul
./browser/components/sessionstore/src/SessionStore.jsm
./browser/components/shell/src/nsWindowsShellService.cpp
./browser/locales/en-US/chrome/browser/aboutSessionRestore.dtd
./browser/locales/en-US/chrome/browser/browser.dtd
./browser/locales/en-US/chrome/browser/browser.properties
./browser/locales/en-US/chrome/browser/safeMode.dtd
./browser/locales/en-US/chrome/overrides/appstrings.properties
./browser/locales/en-US/defines.inc
./browser/locales/en-US/searchplugins/list.txt
./browser/locales/generic/profile/bookmarks.html.in
./browser/locales/jar.mn
./browser/modules/WindowsPreviewPerTab.jsm
./browser/themes/linux/jar.mn
./browser/themes/linux/browser.css
./browser/themes/shared/browser.inc
./modules/libpref/src/init/all.js
./toolkit/components/downloads/nsDownloadManager.h
./toolkit/content/jar.mn
./toolkit/content/resetProfile.js
./toolkit/content/widgets/tabbox.xml
./toolkit/modules/LightweightThemeConsumer.jsm
./toolkit/mozapps/downloads/content/downloads.xul
./toolkit/themes/osx/global/media/TopLevelImageDocument.css
./toolkit/themes/windows/global/media/TopLevelImageDocument.css
./content/html/document/src/ImageDocument.cpp
./content/html/document/src/ImageDocument.h
Since the crashes occur when any menus are opened, my question would be: was anything changed that would relate to drawing of menus? With a cursory glance I found things that had to do with adding some options to the context menu, but nothing more.