Description of problem: Opening preferences when running from console crashes wireshark with an X error. Version-Release number of selected component (if applicable): wireshark-0.99.6-1.fc7 How reproducible: Everytime. Steps to Reproduce: 1. Run wireshark (as non-root). Click 'Run unpriviledged' in the console-helper. 2. Select Edit>Preferences menu item. Actual results: Crash with error below. The program 'wireshark' received an X Window System error. This probably reflects a bug in the program. The error was 'BadIDChoice (invalid resource ID chosen for this connection)'. (Details: serial 3610 error_code 14 request_code 53 minor_code 0) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the --sync command line option to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) Expected results: Shouldn't crash. Additional info: Running via console-helper seems necessary to reproduce bug. Wiped .wireshark after noticing this, and that made no different. gdb could not find gdk_x_error (even after installing gtk2-debuginfo) which might be another bug in itself.
Nb 'running from console' is a typo - I meant 'running from consolehelper'
Strange this is happening only in consolehelper (reproduced in FC6 as well)
I'm afraid I don't know what makes userhelper special. I can't think of any difference userhelper makes when running in unprivileged mode - the UIDs and GIDs are the same, the SELinux context is the same, the environment is the same. In addition, when /usr/sbin/wireshark is replaced by a small binary that exec()s the real wireshark, the crash still happens; when it is replaced by a shell script that exec()s the real wireshark, or by a binary that runs real wireshark in valgrind or gdb, the crash doesn't happen. FWIW: Using xscope shows that the crash happens because wireshark allocates the same X11 resource ID twice: 12.23: Client 2 --> 20 bytes ............REQUEST: CreatePixmap depth: 20 pixmap-id: PXM 03400243 drawable: DWB 0000004d width: 0001 height: 0001 ............REQUEST: GetInputFocus [snip] 12.92: Client 2 --> 40 bytes ............REQUEST: CreateWindow depth: 00 wid: WIN 03400243 parent: WIN 0340023e x: 171 y: 0 width: 0006 height: 001b border-width: 0000 class: InputOnly visual: VIS 00000023 value-mask: event-mask value-list: event-mask: KeyPress | ButtonPress | ButtonRelease | P ointerMotion | PointerMotionHint | StructureNotify | PropertyChange ............REQUEST: GetInputFocus 12.92: 64 bytes <-- X11 Server 2 ..............ERROR: IDChoice bad resource id: 03400243 minor opcode: 0000 major opcode: 01 ..............REPLY: GetInputFocus revert-to: Parent focus: WIN 03400162 That would indicate one of: * memory corruption, affecting Display->resource_id or related variables * incorrect locking in a multithreaded application - but AFAICS wireshark-0.99.6-1.fc7 doesn't use threads. Just reading the code and GTK documentation, the g_thead_init() and gdk_threads_init() calls in main() should be performed before gtk_init() - but that doesn't affect the binary in question.
Ok, it really turned out to be a wireshark bug. It should be fixed in 0.99.7-2