GNOME Bugzilla – Bug 316262
netapplet quits when running VPN
Last modified: 2005-12-29 18:37:03 UTC
Distribution: SuSE Linux 9.3 (i586) Package: netapplet Severity: minor Version: GNOME2.10.0 unspecified Gnome-Distributor: SUSE Synopsis: netapplet quits when running VPN Bugzilla-Product: netapplet Bugzilla-Component: applet Bugzilla-Version: unspecified BugBuddy-GnomeVersion: 2.0 (2.10.0) Description: Description of the crash: My employer provides Cisco's VPN3000 product for access to its internal network. Every time I connect to the internal network, I get a pop-up saying that netapplet quit unexpectedly. Steps to reproduce the crash: 1. Install VPN3000 client 2. Start netapplet 3. Connect to a VPN3000 server Expected Results: Ideally, netapplet would track the changes caused by connecting to the VPN (e.g., different local IP address). It would be okay if netapplet just said "I'm confused" and then waited for the network to return to sanity (when I exit the VPN session). I could live with it exiting gracefully, too, I suppose. How often does this happen? Every time. Additional Information: I certainly don't view this as a high-priority problem, but I thought I'd mention it in case you want to fix the error handling. Debugging Information: Backtrace was generated from '/opt/gnome/bin/netapplet' (no debugging symbols found) Using host libthread_db library "/lib/tls/libthread_db.so.1". (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread 1088849344 (LWP 18989)] (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) 0x4070ddce in __waitpid_nocancel () from /lib/tls/libpthread.so.0
+ Trace 62992
Thread 1 (Thread 1088849344 (LWP 18989))
------- Bug moved to this database by unknown@gnome.bugs 2005-09-14 04:13 UTC ------- The original reporter of this bug does not have an account here. Reassigning to the person who moved it here, unknown@gnome.bugs. Previous reporter was m.kupfer@acm.org.
Thanks for the bug report. This particular bug has already been reported into our bug tracking system, but the maintainers need more information to fix the bug. Could you please answer the questions in the other report? *** This bug has been marked as a duplicate of 300296 ***
No, Mike, the first stack trace is indeed a duplicate of bug 300296 .Teppo was right. the new stack trace, i.e. the one in Comment #3 in this report, and the one you postet in bug 300296, are different. Please do as I told you in 300296 and open a *new* report and paste the last trace there. Thanks. It is an excellent stack trace and will be very helpful in fixing the bug. *** This bug has been marked as a duplicate of 300296 ***
I have filed a new report here: bug 325235 asking Olav to remove the stack trace from this report (and the other) since this confuses our simple-dup-finder
Removing bad stacktrace.
Whenever I reproduce the problem with a non-debug netapplet, I get the backtrace that I originally filed for this bug. When I reproduce the problem with a debug netapplet, I get the trace that has been filed under bug 325235. So I'm feeling a little confused here. If these are in fact different bugs, why would I reliably tickle one bug with the debug rpm and the other bug with a non-debug rpm? Are there differences in the rpms other than the existence of debugging symbols? (And good luck tracking down the bug that only is triggered with the non-debug rpm :-/ )