Cannot reproduce: see http://wstaw.org/m/2013/06/27/plasma-desktopYp2540.png
Also, backtrace looks weird:
#0  0x00007ffff7772cf9 in std::string::compare(std::string const&) const () from /usr/lib64/libstdc++.so.6
#1  0x00007ffff2f50680 in std::pair<std::_Rb_tree_iterator<std::string>, bool> std::_Rb_tree<std::string, std::string, std::_Identity<std::string>, std::less<std::string>, std::allocator<std::string> >::_M_insert_unique<std::string const&>(std::string const&) ()
   from /usr/lib64/firefox-22.0/libxul.so
#2  0x00007ffff2f53d08 in std::set<std::string, std::less<std::string>, std::allocator<std::string> >::insert(std::string const&) ()
   from /usr/lib64/firefox-22.0/libxul.so
#3  0x00007fffe8316d8b in Oxygen::QtSettings::addIconTheme (this=this@entry=0x7fffe9c26018, pathList=..., theme=...)

Symbols "std::set::insert should definitly not be taken from libXul.so but from libstdc++
Seems like your version of firefox as its own set of stl embedded, which most likely conflicts with the one from stdc++ 

Are you building your own firefox ? 
Possibly there is a problem with your LD_LIBRARY_PATH, which, in turn, might be different depending on the DE you are using. Can you double-check that too ?

You say it works normally in XFCE. Were you still using oxygen-gtk in XFCE?
BTW, I can't reproduce on Ubuntu Precise as well as LFS with firefox downloaded from firefox.com.

If you can provide the information requested in comment #1 and/or comment #2, please add it.

sorry for the late reply, I was trying to guess what's happening but with no luck

(In reply to comment #1)
> Cannot reproduce: see http://wstaw.org/m/2013/06/27/plasma-desktopYp2540.png
> Also, backtrace looks weird:
> #0  0x00007ffff7772cf9 in std::string::compare(std::string const&) const ()
> from /usr/lib64/libstdc++.so.6
> #1  0x00007ffff2f50680 in std::pair<std::_Rb_tree_iterator<std::string>,
> bool> std::_Rb_tree<std::string, std::string, std::_Identity<std::string>,
> std::less<std::string>, std::allocator<std::string>
> >::_M_insert_unique<std::string const&>(std::string const&) ()
>    from /usr/lib64/firefox-22.0/libxul.so
> #2  0x00007ffff2f53d08 in std::set<std::string, std::less<std::string>,
> std::allocator<std::string> >::insert(std::string const&) ()
>    from /usr/lib64/firefox-22.0/libxul.so
> #3  0x00007fffe8316d8b in Oxygen::QtSettings::addIconTheme
> (this=this@entry=0x7fffe9c26018, pathList=..., theme=...)
> 
> Symbols "std::set::insert should definitly not be taken from libXul.so but
> from libstdc++
> Seems like your version of firefox as its own set of stl embedded, which
> most likely conflicts with the one from stdc++ 
> 
> Are you building your own firefox ? 

yes, I'm compiling it on a clean slackware64-14.0 using this build script (I link the one of -current just because it's updated for 22.0) http://slackware.osuosl.org/slackware64-current/source/xap/mozilla-firefox/
I tried downloading the binary from mozilla.org and that actually doesn't segfault, this leave me with some doubts...

> Possibly there is a problem with your LD_LIBRARY_PATH, which, in turn, might
> be different depending on the DE you are using. Can you double-check that
> too ?

LD_LIBRARY_PATH seems to be unset in the environment, but maybe it's unrelated because it should crash the same way also when I remove oxygen-gtk2 and it doesn't.

(In reply to comment #2)
> You say it works normally in XFCE. Were you still using oxygen-gtk in XFCE?

no, but if I select it as a theme I got the same behaviour.
actually, if I select it as a theme also the xfce application menu crashes.

ftp://ftp.slackware.com/pub/slackware/slackware64-14.0/ChangeLog.txt

slackware stable had to switch to the ESR version of firefox because of this.

@ponce
I've found some time to try installing Slackware from DVD image under QEMU, running a KDE session, running firefox after installing it from DVD xap directory. This bug can't reproduce with the steps you've given because firefox appears to be version 15 there — far from 22 mentioned in this report.
So, please, make sure you provide all the steps required to reproduce the bug.

hi Ruslan,

firefox-14.0 was the latest version available at the time of Slackware*-14.0 release (end of september 2012).
after a stable release only security fixes goes in, and usually firefox's new releases contain security fixes, so it has been updated gradually, one release after the other, as you can see in the ChangeLog linked above.
the other packages remain frozen at the versions of release time (kde at 4.8.5 and oxygen-gtk2 at 1.3.0).
when firefox-22.0 came out (well, actually since the first betas), I tried building it as I had to send some unrelated patches for the mozilla-firefox.SlackBuild script to Patrick Volkerding and I had to test if they were compatible with the new version, and testing the resulting packages built on slackware stable (everything is rebuilt from source, generally prebuilt binaries are avoided) resulted in the behaviour described in the first post of the bug report.

to have the behaviour described there, you should (as root) download this folder http://slackware.osuosl.org/slackware64-current/source/xap/mozilla-firefox/ and enter it

lftp -c mirror http://slackware.osuosl.org/slackware64-current/source/xap/mozilla-firefox/
cd mozilla-firefox

then launch the build script like this (I suggest to disable PGO as is not important, also speeds up building and uses less RAM)

chmod +x mozilla-firefox.SlackBuild
PGO=no ./mozilla-firefox.SlackBuild

to build it will use 7 jobs: to use X jobs pass the variable NUMJOBS=" -j X " to the slackbuild like the PGO one.
If a PGO build is enabled I suggest also to use 12 Gb of RAM or it may crash during build: the vm can have just 2 Gb of RAM assigned, but a big swap file is needed in this case, as it's used during linking.
I usually do like this

fallocate -l 10G /swapfile
mkswap /swapfile
swapon /swapfile

when the package is ready, upgrade the installed one

upgradepkg mozilla-firefox-22.0-x86_64-1.txz

then try again launching it.

Well, I'm not really ready to build such a big package on a virtual machine :) Especially given the RAM/swap needed.
So we'll go another way. It seems this should be related to the way you build ff since official packages, as you say, work correctly. Does ff 21 built with the same script crash in the same way? What if you try your older script (which was used to build ff 21) on ff 22?

actually that's what I tried first (and what I think Volkerding too tested building 22 with).

the patches I sent just turns on (optionally, and I tested also without enabling them) some internationalization-related configure variables (to have the possibility to do a localized build).
you can see the old build script here http://slackware.osuosl.org/slackware64-14.0/patches/source/mozilla-firefox/mozilla-firefox.SlackBuild

just now I tried also building 21 with the build script I linked above for testing and I can confirm that 21 doesn't show the problem reported (as it hasn't shown it when it has been updated may 15th).

Could you provide a crashing built firefox package to download if possible, so I could test it not spending hours to build? (Preferably 32-bit version since I have 32-bit Slackware installed).
Thanks.

if you could wait some time (a day or two, I have to install a clean 32bit system on a vm) I could build it for you, but the problem is that a package built with the configure option --enable-official-branding (like the slackbuild does) is not redistributable at all (only Volkerding is authorized by the mozilla foundation to redistribute such a Slackware package).
and if built without that option the binary is very different (it's also named differently so the build script should probably have to be modified)...

> if you could wait some time
I can wait as long as necessary (don't have any other option).
> I have to install a clean 32bit system on a vm
Why use a VM if you can cross-compile just using gcc -m32 flag (and installing some 32 bit packages — see [1])?
> but the problem is that a package built with the configure option --enable-official-branding (like the slackbuild does) is not redistributable at all
Well, to me this doesn't make too much difference whether this option is used as long as it doesn't affect reproducibility of crash. (maybe you could ask permission or something from Patrick (so that this looked to be done by him) so that MoFo couldn't sue you for debugging problem with their browser :) )
I think though that this option shouldn't be necessary.

[1]: https://developer.mozilla.org/ja/docs/Compiling_32-bit_Firefox_on_a_Linux_64-bit_OS

Hi Ruslan,

I tested right now on two fresh installs of slackware-14.0 and slackware64-14.0 and the segfault manifests only on 64bit Slackware (the version I tested on previously), I should add also this between the requisites for reproduction, sorry for not having noticed it earlier.

OK, I can finally reproduce this on 64 bit slackware.

Does this reproduce with firefox-23?

yes, I tried it with 23.0.1 and with 24.0b7.
I also tried updating to oxygen-gtk2-1.4.0 but still segfaults.

I have 24.2.0 here and no crash.
Can you try ?

I'll check as soon as possible: please give me some time as building takes a lot.

I just rebuilt firefox-24.2.0 on a fresh installed slackware64-14.0 and tried to launch it under kde with a newly created user (default gtk theme is oxygen-gtk2), and still got a segfault.

Thank you for the bug report.

As this report hasn't seen any changes in 5 years or more, we ask if you can please confirm that the issue still persists.

If this bug is no longer persisting or relevant please change the status to resolved.

Firefox no longer uses GTK2, so this is obsolete. Not sure what status should be set to this report.

well, it actually stopped crashing a while ago, before the switch to gtk+3 (and I wasn't able to pinpoint the actual cause): I confess I forgot to report here, sorry...