Created attachment 1427249 [details] The files in the abrt directory Description of problem: It happens when I log in. Version-Release number of selected component (if applicable): cinnamon-menus-3.6.0-3.fc28.x86_64 cinnamon-control-center-3.6.6-0.1.20180314gitd63b51c.fc28.x86_64 cinnamon-screensaver-3.6.1-4.fc28.x86_64 cinnamon-desktop-3.6.3-0.5.20180218git119a96b.fc28.x86_64 imsettings-cinnamon-1.7.3-3.fc28.x86_64 cinnamon-themes-1.6.2-0.5.20180408git0a7f930.fc28.noarch cinnamon-settings-daemon-3.6.3-0.1.20180214git63f501e.fc28.x86_64 cinnamon-session-3.6.1-3.fc28.x86_64 cinnamon-applet-blueberry-1.1.20-6.fc28.noarch cinnamon-3.6.8-0.7.20180328git8262210.fc28.x86_64 cinnamon-control-center-filesystem-3.6.6-0.1.20180314gitd63b51c.fc28.x86_64 cinnamon-translations-3.6.2-2.fc28.noarch How reproducible: 100% Steps to Reproduce: 1. Login 2. 3. Additional info: I made sure there are no applets that are not supported with this version
Works fine here, feel free to reassign to whatever graphics driver you use.
(In reply to leigh scott from comment #1) > Works fine here, feel free to reassign to whatever graphics driver you use. Its not a driver issue because when I login I get the "Cinnamon just crashed. You are running in fallback Mode." Do you want to restart Cinnamon? Plus when I log in with GNOME or Openbox everything works It is a Cinnamon issue... Please put a little more effort in debugging this... or tell me how to
I can reproduce with the RC 1.1 live medium on a Lenovo X220 (Intel 2nd Gen. GPU / i915); Cinnamon crashes immediatly after auto-login. Anyways, it doesn't happen anymore after updating to Cinnamon-3.8.0-2.fc28 from updates-testing (which is on its way to stable).
(In reply to Steve Dickson from comment #2) > It is a Cinnamon issue... Please put a little more effort > in debugging this... or tell me how to I haven't got the time to ask for info or provide debugging tips. Provide enough info and logs or don't bother spamming me with shit! If I was paid £70000 - £80000 per year to do this I would have a much better attitude, all it does currently is take a large chunk of my free time.
(In reply to Björn 'besser82' Esser from comment #3) > I can reproduce with the RC 1.1 live medium on a Lenovo X220 (Intel 2nd Gen. > GPU / i915); Cinnamon crashes immediatly after auto-login. > > Anyways, it doesn't happen anymore after updating to Cinnamon-3.8.0-2.fc28 > from updates-testing (which is on its way to stable). Thanks! But... I downloaded and installed this koji build https://koji.fedoraproject.org/koji/buildinfo?buildID=1075715 and I got this crash abrt-server[2835]: Package 'cinnamon' isn't signed with proper key any ideas?
(In reply to leigh scott from comment #4) > (In reply to Steve Dickson from comment #2) > > > It is a Cinnamon issue... Please put a little more effort > > in debugging this... or tell me how to > > I haven't got the time to ask for info or provide debugging tips. > Provide enough info and logs or don't bother spamming me with shit! Please see the attachment to this bug... its has all the abrt info which is been available since I opened up the bug Also, if you don't have the time the please stop answering bugs since its a waste of all our time...
(In reply to Steve Dickson from comment #6) > (In reply to leigh scott from comment #4) > > (In reply to Steve Dickson from comment #2) > > > > > It is a Cinnamon issue... Please put a little more effort > > > in debugging this... or tell me how to > > > > I haven't got the time to ask for info or provide debugging tips. > > Provide enough info and logs or don't bother spamming me with shit! > Please see the attachment to this bug... its has all the abrt info > which is been available since I opened up the bug > > Also, if you don't have the time the please stop answering bugs > since its a waste of all our time... Do you want me to add your email ady to my spam filter?, if not shut the f*** up. Why the hell should I waste my resources processing your abrt crash?, more (and cpu time) time I don't have, any more reports from you like this will be closed as 'insufficient info'. If your too lazy to process the abrt data yourself and provide a proper backtrace don't bother reporting issues!
Leigh, this is not even close to acceptable behavior for a Fedora contributor. I'm frankly a bit shocked to see this, and saddened. I know we all have stressful days, and trust me, I get that it can be exhausting to help people diagnose problems, but that's not an excuse for this kind of reaction. Please review the Fedora code of conduct (https://docs.fedoraproject.org/fedora-project/project/codeofconduct.html), apologize, and in the future treat other Fedora users with the respect and friendliness becoming of a Fedora Project member.
(In reply to Matthew Miller from comment #8) > Leigh, this is not even close to acceptable behavior for a Fedora > contributor. It my terms or none, why the hell should I process this persons abrt data. It is the users task to process it, not mine! I right close the bug as 'works for me' but he bitched about it. He has provide zero info but expects support. Why are you getting involved, is he one of you redhat bum chums or something? > I'm frankly a bit shocked to see this, and saddened. I know we > all have stressful days, and trust me, I get that it can be exhausting to > help people diagnose problems, but that's not an excuse for this kind of > reaction. Get used to it, I have autism! > Please review the Fedora code of conduct > (https://docs.fedoraproject.org/fedora-project/project/codeofconduct.html), > apologize, and in the future treat other Fedora users with the respect and > friendliness becoming of a Fedora Project member. No.
(In reply to leigh scott from comment #9) > > I'm frankly a bit shocked to see this, and saddened. I'm also saddened by the crappy bug reporting skills of this redhat employee, I expect much better reporting skills than this.
(In reply to Steve Dickson from comment #5) > (In reply to Björn 'besser82' Esser from comment #3) > > I can reproduce with the RC 1.1 live medium on a Lenovo X220 (Intel 2nd Gen. > > GPU / i915); Cinnamon crashes immediatly after auto-login. > > > > Anyways, it doesn't happen anymore after updating to Cinnamon-3.8.0-2.fc28 > > from updates-testing (which is on its way to stable). > Thanks! > > But... I downloaded and installed this koji build > https://koji.fedoraproject.org/koji/buildinfo?buildID=1075715 > > and I got this crash > > abrt-server[2835]: Package 'cinnamon' isn't signed with proper key > > any ideas? I cannot assist you with this problem, as it seems to be a glitch with the auto-signer. Maybe releng folks can provide a clue on this. Anyways, did the new build fix your issue?
builds downloaded directly from koji are not signed. that is how things work.
(In reply to Björn 'besser82' Esser from comment #11) > (In reply to Steve Dickson from comment #5) > > (In reply to Björn 'besser82' Esser from comment #3) > > > I can reproduce with the RC 1.1 live medium on a Lenovo X220 (Intel 2nd Gen. > > > GPU / i915); Cinnamon crashes immediatly after auto-login. > > > > > > Anyways, it doesn't happen anymore after updating to Cinnamon-3.8.0-2.fc28 > > > from updates-testing (which is on its way to stable). > > Thanks! > > > > But... I downloaded and installed this koji build > > https://koji.fedoraproject.org/koji/buildinfo?buildID=1075715 > > > > and I got this crash > > > > abrt-server[2835]: Package 'cinnamon' isn't signed with proper key > > > > any ideas? > > > I cannot assist you with this problem, as it seems to be a glitch with the > auto-signer. Maybe releng folks can provide a clue on this. Anyways, did > the new build fix your issue? Maybe... It did still crash in the same manner... but "the crashed in _GLOBAL__sub_I_Unified_cpp_js_src12.cpp()" appear so I'm guessing the crash was caused by the signing issue. I'll downgrade and wait for the compose to happen...
(In reply to Dennis Gilmore from comment #12) > builds downloaded directly from koji are not signed. that is how things work. Thanks for the info!
Unfortunately upgrading to cinnamon-3.8.0-2.fc28 did not solve the problem I'm still seeing the SIGSEGV in _GLOBAL__sub_I_Unified_cpp_js_src12.cpp () Looking at the backtrace it appears a dlopen() fails when called from a module_manager called libmodman Here is the top of the backtrace 0 0x00007f97b95452ee in _GLOBAL__sub_I_Unified_cpp_js_src12.cpp () from /lib64/libmozjs-38.so [Current thread is 1 (Thread 0x7f985399b640 (LWP 2902))] Missing separate debuginfos, use: dnf debuginfo-install cinnamon-3.8.0-2.fc28.x86_64 (gdb) bt #0 0x00007f97b95452ee in _GLOBAL__sub_I_Unified_cpp_js_src12.cpp () from /lib64/libmozjs-38.so #1 0x00007f98537de6ba in call_init.part () from /lib64/ld-linux-x86-64.so.2 #2 0x00007f98537de7b6 in _dl_init () from /lib64/ld-linux-x86-64.so.2 #3 0x00007f98537e294f in dl_open_worker () from /lib64/ld-linux-x86-64.so.2 #4 0x00007f984ac97cdf in _dl_catch_exception () from /lib64/libc.so.6 #5 0x00007f98537e21c7 in _dl_open () from /lib64/ld-linux-x86-64.so.2 #6 0x00007f98475a8006 in dlopen_doit () from /lib64/libdl.so.2 #7 0x00007f984ac97cdf in _dl_catch_exception () from /lib64/libc.so.6 #8 0x00007f984ac97d6f in _dl_catch_error () from /lib64/libc.so.6 #9 0x00007f98475a8715 in _dlerror_run () from /lib64/libdl.so.2 #10 0x00007f98475a8096 in dlopen@@GLIBC_2.2.5 () from /lib64/libdl.so.2 #11 0x00007f9815feeae5 in libmodman::module_manager::load_file(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, bool) () from /lib64/libmodman.so.1 #12 0x00007f9815fef51b in libmodman::module_manager::load_dir(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, bool) () from /lib64/libmodman.so.1 #13 0x00007f98161fee41 in libproxy::proxy_factory::proxy_factory() () from /lib64/libproxy.so.1 I'll upload abrt directory
Created attachment 1430150 [details] The abrt directory: abrt-05-02-11.bzip2 Here is all the files under abrt directory...
(In reply to Steve Dickson from comment #15) > Unfortunately upgrading to cinnamon-3.8.0-2.fc28 did not solve the problem > I'm still seeing the SIGSEGV in _GLOBAL__sub_I_Unified_cpp_js_src12.cpp () > > Looking at the backtrace it appears a dlopen() fails when called > from a module_manager called libmodman > > Here is the top of the backtrace > 0 0x00007f97b95452ee in _GLOBAL__sub_I_Unified_cpp_js_src12.cpp () > from /lib64/libmozjs-38.so > [Current thread is 1 (Thread 0x7f985399b640 (LWP 2902))] > Missing separate debuginfos, use: dnf debuginfo-install > cinnamon-3.8.0-2.fc28.x86_64 > (gdb) bt > #0 0x00007f97b95452ee in _GLOBAL__sub_I_Unified_cpp_js_src12.cpp () > from /lib64/libmozjs-38.so > #1 0x00007f98537de6ba in call_init.part () from /lib64/ld-linux-x86-64.so.2 > #2 0x00007f98537de7b6 in _dl_init () from /lib64/ld-linux-x86-64.so.2 > #3 0x00007f98537e294f in dl_open_worker () from /lib64/ld-linux-x86-64.so.2 > #4 0x00007f984ac97cdf in _dl_catch_exception () from /lib64/libc.so.6 > #5 0x00007f98537e21c7 in _dl_open () from /lib64/ld-linux-x86-64.so.2 > #6 0x00007f98475a8006 in dlopen_doit () from /lib64/libdl.so.2 > #7 0x00007f984ac97cdf in _dl_catch_exception () from /lib64/libc.so.6 > #8 0x00007f984ac97d6f in _dl_catch_error () from /lib64/libc.so.6 > #9 0x00007f98475a8715 in _dlerror_run () from /lib64/libdl.so.2 > #10 0x00007f98475a8096 in dlopen@@GLIBC_2.2.5 () from /lib64/libdl.so.2 > #11 0x00007f9815feeae5 in > libmodman::module_manager::load_file(std::__cxx11::basic_string<char, > std::char_traits<char>, std::allocator<char> >, bool) () > from /lib64/libmodman.so.1 > #12 0x00007f9815fef51b in > libmodman::module_manager::load_dir(std::__cxx11::basic_string<char, > std::char_traits<char>, std::allocator<char> >, bool) () > from /lib64/libmodman.so.1 > #13 0x00007f98161fee41 in libproxy::proxy_factory::proxy_factory() () > from /lib64/libproxy.so.1 > > I'll upload abrt directory Cinnamon uses mozjs52 not 38 everything cinnamon in f28 repo was built against mozjs52 As you still haven't provided processed abrt I'm closing this issue as 'insufficient data'.
*** This bug has been marked as a duplicate of bug 1573643 ***
(In reply to leigh scott from comment #17) > > Cinnamon uses mozjs52 not 38 > > everything cinnamon in f28 repo was built against mozjs52 > > As you still haven't provided processed abrt I'm closing this issue as > 'insufficient data'. These are bzip2 tarballs that were added when I opened up this bz. https://bugzilla.redhat.com/attachment.cgi?id=1427249 https://bugzilla.redhat.com/attachment.cgi?id=1430150 If these are not what you are looking for, what is?
(In reply to leigh scott from comment #17) > Cinnamon uses mozjs52 not 38 > > everything cinnamon in f28 repo was built against mozjs52 dnf remove mozjs38 did solve the problem... Thank you!