Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 204459 - net-analyzer/wireshark-0.99.7 X errors
Summary: net-analyzer/wireshark-0.99.7 X errors
Status: VERIFIED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Netmon Herd
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-01-05 19:00 UTC by M. Edward Borasky
Modified: 2008-01-11 08:29 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
emerge --info from my system (infox,3.74 KB, text/plain)
2008-01-05 19:40 UTC, M. Edward Borasky
Details

Note You need to log in before you can comment on or make changes to this bug.
Description M. Edward Borasky 2008-01-05 19:00:31 UTC
I have wireshark-0.99.7 installed and I'm trying to do a capture. I started it up and pressed the leftmost button to search for interfaces. At that point, it dumped a bunch of errors on the screen and stopped responding to the mouse. Here's what it dumped:

$ wireshark
Xlib: unexpected async reply (sequence 0x1f34)!
Xlib: unexpected async reply (sequence 0x1f35)!
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 7990 error_code 14 request_code 1 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.)
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 7998 error_code 14 request_code 1 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.)
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 8009 error_code 14 request_code 132 minor_code 2)
  (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.)
znmeb@DreamScape ~ $ Xlib: sequence lost (0x10000 > 0x1f35) in reply type 0x0!
Xlib: sequence lost (0x10000 > 0x1f40) in reply type 0x21!
Xlib: sequence lost (0x10000 > 0x1f40) in reply type 0x0!
Xlib: sequence lost (0x10000 > 0x1f40) in reply type 0x0!


It's essentially unusable. It was compiled with USE flags:

$ emerge -pv wireshark

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild   R   ] net-analyzer/wireshark-0.99.7  USE="gtk ipv6 kerberos portaudio ssl threads -adns (-selinux) -snmp" 0 kB 


I'm going to try recompiling it without portaudio and threads to see if that helps.
Comment 1 Jakub Moc (RETIRED) gentoo-dev 2008-01-05 19:18:58 UTC
Post your emerge --info please.
Comment 2 M. Edward Borasky 2008-01-05 19:40:12 UTC
Created attachment 140221 [details]
emerge --info from my system
Comment 3 M. Edward Borasky 2008-01-06 19:39:55 UTC
The recompile without threads and portaudio and a reboot seems to have fixed this. So this may not be reproducible. I'm planning to try the threads and portaudio flags later today to see if I can get the problem back. This is a dual-core box, so I'm really suspicious about the threads option.
Comment 4 Kevin Pyle 2008-01-08 05:53:23 UTC
I can reproduce this at will.  It is not related to USE=threads.  This is an upstream bug.  To get the list of interfaces, Wireshark defers to the privileged helper process dumpcap.  The function capture_sync.c!sync_pipe_open_command forks and execs a dumpcap helper.  However, if the child process fails to exec dumpcap, it *returns* instead of calling _exit.  The parent and child process both run wireshark code and both use the same X11 socket and X11 windows.

I suspect Mr. Borasky added his user to the wireshark group upon completion of the wireshark emerge, but did not log out to pick up the new group id.  Shells which lacked the wireshark group launched a Wireshark that was not able to exec /usr/bin/dumpcap, hence the manifestation of the bug.  When he rebooted, his new shells picked up the new group id, and a wireshark launched from them was able to exec dumpcap.  For reference to readers who do not have Wireshark handy, /usr/bin/dumpcap is installed as root:wireshark 4710 on Gentoo.  In my case, the user account that runs Wireshark is not in the wireshark group, and there are no plans to grant that user permission to do live captures.  Wireshark is used only to provide a GUI for pcap files generated by other programs.

There are a few workarounds for users who are affected:
(1) Put users who need to run Wireshark in the wireshark group.  This grants them permission to run live captures, so it may not be acceptable from a security standpoint.
(2) Make /usr/bin/dumpcap mode 711.  This strips all non-root users of the ability to perform live captures through Wireshark, but it does avoid crashing non-root users who are not in the wireshark group.  In my brief testing, it also broke most other privileged operations, such as populating the list of interfaces.
(3) Move /usr/bin/dumpcap to a new name and replace it with a shell script which will execute the real dumpcap or exit with a failure code.  This script should be mode 0755, but the real dumpcap should remain mode 4710.  In this mode, the script allows the exec in the child process to succeed, so a subsequent permission failure does not leave a second wireshark process running.  In my brief testing, this seems to work correctly both for users in the wireshark group and for users not in the wireshark group.  Users who are not in the wireshark group do not crash, but do not receive any error messages explaining why the interface list is blank.  One possible script is:

#!/bin/sh

[ -x /usr/bin/_dumpcap ] && exec /usr/bin/_dumpcap "${@}"
exit 1


The Netmon herd could patch the Wireshark source to force the child process to exit on failure.  This would be a temporary workaround until upstream issues a proper patch to fix the bug.  The temporary fix should be as simple as adding a call to _exit(1) at line 652 in capture_sync.c for Wireshark 0.99.7.  I have not tried this.  Hopefully, upstream can provide a more comprehensive fix that is able to notify the user that the exec failed.  Based on my experience with option (3), I expect that the proposed temporary workaround would also not provide feedback to users that notified them why the interface list was blank.  Even so, such a patch would be an improvement over the current situation, since it would grant them the ability to use Wireshark to view pre-existing pcap files.
Comment 5 M. Edward Borasky 2008-01-08 06:12:35 UTC
Ah ... OK ... if it's upstream, should this bug be closed? I am in the wireshark group -- the ebuild said to do that. :)
Comment 6 Peter Volkov (RETIRED) gentoo-dev 2008-01-08 08:48:08 UTC
Kevin, thank you for your investigation. But is this bug reported upstream if not could you report it http://bugs.wireshark.org/bugzilla/ and give us bug number? I'll backport fix from snv then.
Comment 7 Kevin Pyle 2008-01-09 04:51:16 UTC
(In reply to comment #6):
It is now reported upstream as <http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2177>.

In the meantime, would you consider modifying the Wireshark 0.99.7 ebuild as I suggested in the final paragraph of comment #4?  There does not seem to be any negative side effect on the parent process to having the child process exit silently, and it would be a better user experience to have the interface list come up blank than to have Wireshark completely crash.

(In reply to comment #5):
> Ah ... OK ... if it's upstream, should this bug be closed? I am in the
> wireshark group -- the ebuild said to do that. :)

No, please leave it open until upstream responds.  You only need to be in the wireshark group if you want to run live captures (or avoid this bug).  If, like me, you only use Wireshark to view captures collected through other programs, you do not need to be in the wireshark group.
Comment 8 Kevin Pyle 2008-01-10 00:22:08 UTC
The upstream developer has committed Subversion revision 24040 to http://anonsvn.wireshark.org/wireshark/ and marked the upstream bug as FIXED.  I have not tried the patch, but it looks like it should resolve the issue and provide a notification to the user.
Comment 9 Peter Volkov (RETIRED) gentoo-dev 2008-01-10 18:41:33 UTC
I've backported patch from upstream, This bug is fixed in wireshark-0.99.7-r1. Kevin, thank you very much for your help.
Comment 10 Kevin Pyle 2008-01-11 06:06:23 UTC
net-analyzer/wireshark-0.99.7-r1 does not crash when the exec of /usr/bin/dumpcap fails due to lack of permission.

The user is not notified of the reason for the blank interface list.  However, given the frequency with which Wireshark attempts to spawn the helper process, I prefer the lack of notification.


In my opinion, this bug can be moved to CLOSED.
Comment 11 Peter Volkov (RETIRED) gentoo-dev 2008-01-11 08:29:48 UTC
(In reply to comment #10)
> In my opinion, this bug can be moved to CLOSED.

Actually gentoo developers very rarely move bugs to CLOSED state. There is no policy for this and having bug RESOLVED is not a big problem. But, thank you for reporting back. Closing...