Summary: | knetworkmanager crashes with dbus-1.0.(0|1) | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Avuton Olrich <avuton> |
Component: | New packages | Assignee: | Project Gentopia <gentopia> |
Status: | RESOLVED INVALID | ||
Severity: | normal | ||
Priority: | High | ||
Version: | 2006.1 | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 156867 | ||
Bug Blocks: |
Description
Avuton Olrich
2006-11-18 07:32:52 UTC
Here's the backtrace: Using host libthread_db library "/lib/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread 47604796365792 (LWP 19657)] [KCrash handler] #5 0x00002b4bdad937b5 in *__GI_raise (sig=<value optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #6 0x00002b4bdad94a4e in *__GI_abort () at abort.c:88 #7 0x00002b4bd6806335 in _dbus_abort () at dbus-sysdeps.c:84 #8 0x00002b4bd67fc305 in _dbus_warn_check_failed ( format=0x2b4bd6817820 "arguments to %s() were incorrect, assertion \"%s\" failed in file %s line %d.\nThis is normally a bug in some application using the D-Bus library.\n") at dbus-internals.c:283 #9 0x00002b4bd67dc6d8 in dbus_connection_dispatch (connection=0x56c410) at dbus-connection.c:4213 #10 0x00002b4bd638f3a0 in DBusQt::Connection::dispatchRead (this=0x583370) at ./connection.cpp:119 #11 0x00002b4bd638fabc in DBusQt::Connection::qt_invoke (this=0x583370, _id=8, _o=0x7fffd49ce790) at ./connection.moc:112 #12 0x00002b4bd879494c in QObject::activate_signal (this=0x5834a0, clist=0x583ff0, o=0x7fffd49ce790) at kernel/qobject.cpp:2356 #13 0x00002b4bd8795883 in QObject::activate_signal (this=0x5834a0, signal=2) at kernel/qobject.cpp:2325 #14 0x00002b4bd63900f6 in DBusQt::Internal::Integrator::slotRead ( this=0x5834a0, fd=<value optimized out>) at ./integrator.cpp:169 #15 0x00002b4bd639015e in DBusQt::Internal::Integrator::qt_invoke ( this=0x5834a0, _id=2, _o=0x7fffd49ce940) at ./integrator.moc:233 #16 0x00002b4bd879494c in QObject::activate_signal (this=0x5837d0, clist=0x583c50, o=0x7fffd49ce940) at kernel/qobject.cpp:2356 #17 0x00002b4bd879560a in QObject::activate_signal (this=0x5837d0, signal=2, param=11) at kernel/qobject.cpp:2449 #18 0x00002b4bd8b86080 in QSocketNotifier::activated (this=0x5837d0, t0=11) at .moc/debug-shared-mt/moc_qsocketnotifier.cpp:85 #19 0x00002b4bd87bb85c in QSocketNotifier::event (this=0x5837d0, e=0x7fffd49cee40) at kernel/qsocketnotifier.cpp:258 #20 0x00002b4bd8721aea in QApplication::internalNotify (this=0x7fffd49cf210, receiver=0x5837d0, e=0x7fffd49cee40) at kernel/qapplication.cpp:2635 #21 0x00002b4bd8723a39 in QApplication::notify (this=0x7fffd49cf210, receiver=0x5837d0, e=0x7fffd49cee40) at kernel/qapplication.cpp:2358 #22 0x00002b4bd7a124aa in KApplication::notify (this=0x7fffd49cf210, receiver=0x5837d0, event=0x7fffd49cee40) at kapplication.cpp:550 #23 0x00002b4bd86aa0d4 in QApplication::sendEvent (receiver=0x5837d0, event=0x7fffd49cee40) at ../include/qapplication.h:496 #24 0x00002b4bd8712922 in QEventLoop::activateSocketNotifiers (this=0x548920) at kernel/qeventloop_unix.cpp:578 #25 0x00002b4bd86c0464 in QEventLoop::processEvents (this=0x548920, flags=4) at kernel/qeventloop_x11.cpp:383 #26 0x00002b4bd873f63a in QEventLoop::enterLoop (this=0x548920) at kernel/qeventloop.cpp:198 #27 0x00002b4bd873f443 in QEventLoop::exec (this=0x548920) at kernel/qeventloop.cpp:145 #28 0x00002b4bd872373e in QApplication::exec (this=0x7fffd49cf210) at kernel/qapplication.cpp:2758 #29 0x00002b4bd62386e0 in kdemain (argc=<value optimized out>, argv=<value optimized out>) at main.cpp:55 #30 0x00002b4bdad81394 in __libc_start_main (main=0x4008a0 <main>, argc=1, ubp_av=0x7fffd49cf558, init=<value optimized out>, fini=<value optimized out>, rtld_fini=<value optimized out>, stack_end=0x7fffd49cf548) at libc-start.c:238 #31 0x0000000000400809 in _start () Current language: auto; currently c I'm unsure what else I can do about this bug, but I tried reporting it to the maintainer (it's still broke in svn) and he says it's a libdbus bug. I'm really unsure how to go further with it :/. https://bugzilla.novell.com/show_bug.cgi?id=224081 *** Bug 156867 has been marked as a duplicate of this bug. *** I won't deal with your blatent rudeness. Don't want a bug report from me for this, that's fine. Why don't you treat others how they treat you? > You failed to provide a test case. You want something specific, let me know. I'll give it to you, as I offered so nicely, maybe you could learn something from that. I'm a /user/, I have no idea how to get you a test case. > You failed to mention who you talked to in #dbus. It was completely irrelevant, but Thaigo was the one who told me that it appeared to him to be a miscompile, then I messed around with the -O and it fixed things. > You failed to take into account that D-Bus has no issue for a lot of people on > amd64, including upstream authors, so without a test case, nothing can be > done. Does that matter? The bug exists, weather I'm the only one in the world it hits. This is not a 'bad configuration' problem. It's reproducible. Next person may not actually take the time to figure out the issue. Next time, I definitely won't waste my time, I'll just fix the problem for myself. > You failed to provide a meaningful backtrace in your other bug, > http://www.gentoo.org/proj/en/qa/backtraces.xml Anytime I change -O2 to -O0 it works, see above. How about helping rather than being rude. My CFLAGS are fine for backtracing, if they're not how about being helpful and telling me how I can improve them. If you looked at my CFLAGS they're the same as the link you gave me, minus the O. > And lastly, this is just the same issue in the other bug just reported in a > new bug, hence it's a dup. I wasn't sure this was a dupe. It could have very well been a GCC issue, that's fine. (In reply to comment #4) > I won't deal with your blatent rudeness. Don't want a bug report from me for > this, that's fine. Why don't you treat others how they treat you? If I could file multiple bugs to you and scatter information across multiple locations that will require you to piece together many sources of information for you to read my reply I would.. In addition, this is open source software, I provide tech support to everyone for free. If you don't like the support you get, take your business elsewhere. > > > You failed to provide a test case. > > You want something specific, let me know. I'll give it to you, as I offered so > nicely, maybe you could learn something from that. I'm a /user/, I have no idea > how to get you a test case. Well you're using a source based distro. Grab your compiler and learn how it works. Since your situation is entirely un-reproducible, it's up to you to help yourself a bit. If it's one spot in the code that's constantly crashing, read the how to get a useful backtrace guide that I posted. Then read the further reading about gdb about getting useful data from gdb and look into it. Useful things would be "Oh I always get a NULL for this.. something is not setting it. Oh on line #712 it should be set." It's really not too difficult, help me... help you. It doesn't matter if you're a user, not up to me to run around to solve your problem since after all it's open source. > > > You failed to mention who you talked to in #dbus. > > It was completely irrelevant, but Thaigo was the one who told me that it > appeared to him to be a miscompile, then I messed around with the -O and it > fixed things. Not irrelevant at all, since you didn't provide much useful info into the problem but claimed to have debugged it with someone. I was hoping to talk to that person to get some useful information from them. Before you even replied to this Thiago talked to me. He said it appears to be a gcc miscompiled the code issue. I would tend to agree. Based on the backtrace you posted and the emerge --info you posted. It's clear that you compiled your system with a lot more optimizations then you're willing to admit with emerge --info. I'm willing to bet some of the remnants of that still exist on your system and the only way to clean everything up would be to recompile your whole system. The fact that the code works for you with -0 and nothing else further highlights this point. Also you are using an out of date gcc version if your on ~arch. > > > You failed to take into account that D-Bus has no issue for a lot of people on > > amd64, including upstream authors, so without a test case, nothing can be > > done. > > Does that matter? The bug exists, weather I'm the only one in the world it > hits. This is not a 'bad configuration' problem. It's reproducible. Yes it matters. It means it's your configuration or hardware. If you're the only one in the world that hits it then it highlights it even further, it makes no difference if it's always reproducible on your machine or not, it means its your hardware and software configuration that's a special combo to trigger the issue. Then clearly it's not a bug in the software at hand but an issue with your hardware and software configuration on your machine. > Next time, I definitely > won't waste my time, I'll just fix the problem for myself. > You have that right, if that's what you want. > > You failed to provide a meaningful backtrace in your other bug, > > http://www.gentoo.org/proj/en/qa/backtraces.xml > > Anytime I change -O2 to -O0 it works, see above. How about helping rather than > being rude. My CFLAGS are fine for backtracing, if they're not how about being > helpful and telling me how I can improve them. If you looked at my CFLAGS > they're the same as the link you gave me, minus the O. Your CFLAGS are not fine. Not if you've just changed from ricer flags to the CFLAGS in your emerge --info. Other components of your system are compiled with ricer flags. If you change to -O0 and it works and -O2 does not for you and it works for everyone else then once again... issue specific to your system, that you will need to learn how to debug further provided with the instructions above. > > > And lastly, this is just the same issue in the other bug just reported in a > > new bug, hence it's a dup. > > I wasn't sure this was a dupe. It could have very well been a GCC issue, that's > fine. > You posted part of the problem in one bug. Referenced a second bug and lastly created this bug. Put all information that's related together in one place. > Your CFLAGS are not fine. Not if you've just changed from ricer flags to the
> CFLAGS in your emerge --info. Other components of your system are compiled with
I can't stress enough that I haven't changed my CFLAGS in over a year. Hasn't happened. OK, so I'm guilty of computers not being my #1 job in the world, never made a 'test case' in my life. I would not filed this bug saying there's a problem with GCC if I was screwing around with CFLAGS. So, since we can't seem to get anywhere, this bug won't get fixed, did what I could. Could be the hardware, as a longshot, but I'm not going to be able to help with that. Thanks for your time, it was a real eye-opener.
|