Bug 195980 - net/wireshark: Port and package segfaults on start
Summary: net/wireshark: Port and package segfaults on start
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: amd64 Any
: --- Affects Some People
Assignee: Joe Marcus Clarke
Keywords: needs-qa
Depends on:
Reported: 2014-12-14 22:51 UTC by stoa
Modified: 2014-12-31 10:26 UTC (History)
7 users (show)

See Also:
koobs: maintainer-feedback+

wireshark.gdb (13.51 KB, text/plain)
2014-12-16 00:46 UTC, stoa
no flags Details
Full Backtrace of Segfault (15.03 KB, text/plain)
2014-12-18 02:07 UTC, stoa
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description stoa 2014-12-14 22:51:18 UTC
Built and installed net/wireshark on Dec. 13, 2014. On first start, it core dumped with a seg. fault.  After confirming all shared libs were in place, I deleted and re-build.  No errors during build noted.  Again, upon staring, core dump and seg. fault.

At same time, on a separate machine, installed the package.  Upon first
attempt to run: again, seg. fault and core dump.

Ports machine:10.1-RELEASE #0 r274401: Tue Nov 11 21:02:49 UTC 2014
Packages machine: 10.1-RELEASE #0 r274401: Tue Nov 11 21:02:49 UTC 2014

On ports machine, ran <gdb wireshark wireshark.core> and the last three lines were:

Loaded symbols for /libexec/ld-elf.so.1
#0  0x000000080945ec0b in g_type_check_instance_is_fundamentally_a () 
from /usr/local/lib/libgobject-2.0.so.0
[New Thread 810006400 (LWP 100240/wireshark)]

Both ld-elf.so.1 and libgobject.so.1 are present, and as noted, <pkg check --shlibs> was successful.

Others are having same problem:  from the forums today (12.14.14)[1].

I can provide specifics if requested, but generally the ports machine contains AMD cpu with primarily all NVIDIA drivers and package machine is all-Intel.

If you need further information, please let me know.

[1] https://forums.freebsd.org/threads/wireshark-install.49487/
Comment 1 Bugzilla Automation freebsd_committer 2014-12-14 22:51:18 UTC
Auto-assigned to maintainer marcus@FreeBSD.org
Comment 2 Joe Marcus Clarke freebsd_committer 2014-12-15 20:03:57 UTC
I cannot reproduce.  Can you recompile it, glib and GTK+ with debugging symbols then post the output of a bt full all from gdb?
Comment 3 stoa 2014-12-16 00:03:24 UTC
I'd be glad to, but I haven't done that before, so I would need some slightly more specific instruction.  For example, I tried recompiling wireshark with debugging symbols by way of <portmaster --force-config net/wireshark> but debugging symbols is not an option; lost already.  I'd be glad to take private email instructions so as to not hog up this report.

In the meantime, I did run bt on the core output:

Loaded symbols for /libexec/ld-elf.so.1
#0  0x00000008099b3c0b in g_type_check_instance_is_fundamentally_a () from /usr/local/lib/libgobject-2.0.so.0
[New Thread 810406400 (LWP 100137/wireshark)]
(gdb) run
Starting program: /usr/local/bin/wireshark 
(no debugging symbols found)...[many times]...
Program received signal SIGSEGV, Segmentation fault.
0x00000008099b3c0b in g_type_check_instance_is_fundamentally_a () from /usr/local/lib/libgobject-2.0.so.0
(gdb) bt
#0  0x00000008099b3c0b in g_type_check_instance_is_fundamentally_a () from /usr/local/lib/libgobject-2.0.so.0
#1  0x000000080999c83b in g_object_ref () from /usr/local/lib/libgobject-2.0.so.0
#2  0x0000000809c1993d in g_list_foreach () from /usr/local/lib/libglib-2.0.so.0
#3  0x00000008080babf3 in gtk_window_set_icon_list () from /usr/local/lib/libgtk-3.so.0
#4  0x00000000004445b6 in _start ()
#5  0x0000000809997912 in g_closure_invoke () from /usr/local/lib/libgobject-2.0.so.0
#6  0x00000008099ac593 in g_signal_emitv () from /usr/local/lib/libgobject-2.0.so.0
#7  0x00000008099ad308 in g_signal_emit_valist () from /usr/local/lib/libgobject-2.0.so.0
#8  0x00000008099ada24 in g_signal_emit () from /usr/local/lib/libgobject-2.0.so.0
#9  0x000000080809fd14 in gtk_widget_realize () from /usr/local/lib/libgtk-3.so.0
#10 0x00000000004c1e55 in _start ()
#11 0x00000000004478e2 in _start ()
#12 0x000000000042463f in _start ()
#13 0x0000000800811000 in ?? ()
#14 0x0000000000000000 in ?? ()
Comment 4 stoa 2014-12-16 00:46:10 UTC
Created attachment 150614 [details]
Comment 5 stoa 2014-12-16 00:48:52 UTC
OK - recompiled devel/glib20 and x11-toolkits/gtk30 with debugging.  Ran <gdb wireshark wireshark.core>.  Results attached as wireshark.gdb.
Comment 6 Joe Marcus Clarke freebsd_committer 2014-12-16 00:57:19 UTC
What window manager/desktop are you using?
Comment 7 stoa 2014-12-16 01:08:13 UTC
dwm. Not sure about the other folks at hackers@ and on the forums having the same issue - they didn't mention.
Comment 8 Joe Marcus Clarke freebsd_committer 2014-12-16 18:15:02 UTC
I cannot reproduce with the latest ports using either the GNOME desktop or dwm.  Can you make sure all your ports are up-to-date?
Comment 9 stoa 2014-12-16 18:42:01 UTC
I wish I could offer more.  Unfortunately for me, I was able to reproduce it immediately on my second FBSD machine.  Both are up-to-date (and are kept so on a daily basis), including security patches.  Here are the links [1][2] to the two others who reported the same issue at basically the same time; possibly they could provide some information that I can't.


I don't think I was able to provide the exact debugging information you were looking for; if you could be explicit, I'd be glad to provide whatever information I can.

Thanks for your help so far.
Comment 10 Joe Marcus Clarke freebsd_committer 2014-12-16 18:48:43 UTC
The stack trace points to a GTK+ issue, not necessarily one in wireshark.  It seems to be icon-related.  Do other GTK+ 3 apps crash?  It seems like they really should.
Comment 11 stoa 2014-12-16 19:54:54 UTC
I won't have access to those machines for about 6 hours.  However, I did take a quick look at the ports website and it would seem all the other applications I can think of that I use are using gtk2, not gtk3 (firefox, thunderbird, geany, geeqie).  I do tend to build the same ports on each machine, so both would have a similar package list and hence, similar problems.

When I get access later today, I'll check whether I am running anything besides wireshark that uses gtk3.  (If not, I'll install something to test.)

Also, would it help your analysis if I deleted wireshark and installed wireshark-lite?
Comment 12 stoa 2014-12-17 01:57:47 UTC
I had no other installed applications dependent upon gtk3, so I installed graphics/zathura, a light pdf viewer, which is dependent upon gtk3.

The initial build failed with what appears to be gtk3-related errors:

1 warning generated.
In file included from zathura.c:13:
In file included from /usr/local/include/girara/session.h:11:
In file included from /usr/local/include/gtk-3.0/gtk/gtkx.h:29:
In file included from /usr/local/include/gtk-3.0/gtk/gtksocket.h:34:
In file included from /usr/local/include/gtk-3.0/gdk/gdkx.h:30:
In file included from /usr/local/include/X11/Xlib.h:47:
/usr/local/include/X11/Xfuncproto.h:145:24: warning: named variadic macros are a GNU extension [-Wvariadic-macros]
#define _X_NONNULL(args...)  __attribute__((nonnull(args)))
zathura.c:178:39: warning: 'gtk_alignment_new' is deprecated [-Wdeprecated-declarations]
  zathura->ui.page_widget_alignment = gtk_alignment_new(0.5, 0.5, 0, 0);
/usr/local/include/gtk-3.0/gtk/deprecated/gtkalignment.h:79:12: note: 'gtk_alignment_new' declared here
GtkWidget* gtk_alignment_new        (gfloat             xalign,
zathura.c:1137:24: warning: 'gtk_alignment_new' is deprecated [-Wdeprecated-declarations]
    GtkWidget* align = gtk_alignment_new(0.5, 0.5, 0, 0);
/usr/local/include/gtk-3.0/gtk/deprecated/gtkalignment.h:79:12: note: 'gtk_alignment_new' declared here
GtkWidget* gtk_alignment_new        (gfloat             xalign,
3 warnings generated.
gmake[2]: *** wait: No child processes.  Stop.
===> Compilation failed unexpectedly.
Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to
the maintainer.
*** Error code 1

make[1]: stopped in /usr/ports/graphics/zathura
*** Error code 1

make: stopped in /usr/ports/graphics/zathura

===>>> make build failed for graphics/zathura
===>>> Aborting update

===>>> Installation of x11-toolkits/girara (girara-0.2.3) complete

===>>> You can restart from the point of failure with this command line:
       portmaster <flags> graphics/zathura

I did re-build with MAKE_JOBS_UNSAFE=yes, and the build succeeded and the application works.

Hope this helps.  If you need anything else tested, please let me know.
Comment 13 sasha 2014-12-18 01:57:14 UTC
Hi Joe,

I had some additional comments, but my email reply to you was bounced.  Just as well to put everything here.

Yes, I did install from ports on one machine, but because I use both ports and pkg I wondered if some problem might have arisen.  Upon reinstallation of wireshark, the program never progressed to the point of creating a ~/.wireshark directory.  On one of the machines I went to the extent of deleting all installed packages, removing my /usr/ports and /var/db/portsnap directories.  I then re-installed the portstree and built from ports in the following order: gtk3, xorg-minimal, xterm, wireshark, fluxbox, firefox.  I also tried installing the full-blown gnome3.  None of these efforts have yielded results although I agreee that it seems like a gtk+ related issue.

Running gdb on the wireshark.core, I got essentially the same output as stoa.
Program received signal SIGSEGV, Segmentation fault.

[Switching to Thread 80f407400 (LWP 100091/wireshark)]
0x0000000809046d45 in g_type_check_instance_is_fundamentally_a ()
   from /usr/local/lib/libgobject-2.0.so.0
(gdb) backtrace
#0  0x0000000809046d45 in g_type_check_instance_is_fundamentally_a ()
   from /usr/local/lib/libgobject-2.0.so.0
   #1  0x000000080902f16e in g_object_ref () from /usr/local/lib/libgobject-2.0.so.0
   #2  0x00000008092ac0fd in g_list_foreach () from /usr/local/lib/libglib-2.0.so.0
   #3  0x000000080775b585 in gtk_window_set_icon_list () from /usr/local/lib/libgtk-3.so.0
   #4  0x0000000000444ac1 in _start ()
   #5  0x000000080902aed3 in g_closure_invoke () from /usr/local/lib/libgobject-2.0.so.0
   #6  0x000000080903ffff in g_signal_has_handler_pending () from /usr/local/lib/libgobject-2.0.so.0
   #7  0x00000008090421e2 in g_signal_emit_valist () from /usr/local/lib/libgobject-2.0.so.0
   #8  0x0000000809042933 in g_signal_emit () from /usr/local/lib/libgobject-2.0.so.0
   #9  0x000000080774b128 in gtk_widget_realize () from /usr/local/lib/libgtk-3.so.0
   #10 0x00000000004bd5d1 in _start ()
   #11 0x0000000000447518 in _start ()
   #12 0x00000000004240ee in _start ()
   #13 0x000000080080c000 in ?? ()
   #14 0x0000000000000000 in ?? ()
(gdb) x 0x0000000809042933
0x809042933 <g_signal_emit+131>:        0xd8c48148
(gdb) n
Single stepping until exit from function g_type_check_instance_is_fundamentally_a,
which has no line number information.

Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.

I should also mention that tshark works just fine.  Also, I have never had this problem with earlier versions of wireshark.  Three of my machines (two laptops and one desktop) have been running wireshark for a couple years.
Comment 14 stoa 2014-12-18 02:07:57 UTC
Created attachment 150705 [details]
Full Backtrace of Segfault
Comment 15 stoa 2014-12-18 02:12:31 UTC
I think I was able to re-compile wireshark with full debugging symbols.  See attachment "Full Backtrace of Segfault."
Comment 16 Joe Marcus Clarke freebsd_committer 2014-12-18 05:59:42 UTC
The code in that area of wireshark hasn't changed recently.  The problem must be in GTK+.  If you try backing out a version or two of gtk30, perhaps the crash goes away.  However, that doesn't explain why it works for me.  Have you tried launching wireshark from a new, clean account?
Comment 17 sasha 2014-12-18 16:24:17 UTC
I did try with a newly created user.  Same result.  I am curious, Joe, are all of your installed ports/packages up-to-date?  If not, that might be why you can't rep[roduce the problem.
Comment 18 Joe Marcus Clarke freebsd_committer 2014-12-18 16:27:08 UTC
Yes, they are up-to-date as of yesterday.  Can you try backing down to a previous gtk30 version?
Comment 19 Joe Marcus Clarke freebsd_committer 2014-12-18 17:14:08 UTC
Have a look at https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195455 .  Seems this icon theme is required.  You might try installing it and see if it helps.
Comment 20 sasha 2014-12-18 22:35:19 UTC
experiment#1: i took it back to r367132 (gtk3-3.8.8_1).  installed adwaita-icon-theme.  same result.

experiment#2: edit makefile to require/use gtk2 instead of gtk3. build went without complaint.  segfault as usual with same output from gdb

experiment#3: install on a machine that had no previous installation of wireshark and try to run from a newly created user.  same result.
Comment 21 Joe Marcus Clarke freebsd_committer 2014-12-18 22:44:49 UTC
What environment settings are you using?  Maybe this is locale related.
Comment 22 Joe Marcus Clarke freebsd_committer 2014-12-18 22:47:02 UTC
You might also try reverting to wireshark 1.12.1 to see if it crashes (you had said earlier versions did not).  All of the 1.12 releases have used gtk30 (and simply changing to gtk20 in the Makefile won't get it to build with gtk20; you need to change the configure options as well).
Comment 23 sasha 2014-12-20 21:41:40 UTC
Of course I changed the configure options as well.

I tried downgrading, and still crashed.  Oddly, even downgrading to a version that used to work still crashes.

I tried deleting ALL installed packages, except pkg, followed by pkg clean -a.  I then ran pkg upgrade -f pkg.

I carefully read the README, README.bsd, INSTALL and INSTALL.configure files in the wireshark work folder.  In README.bsd the user is exhorted to make sure several programs were installed before wireshark.  These included glib2 (presumably glib20, since there is no glib2 in the ports tree), pkgconfig (which might be pkg-config, which is deprecated, or pkgconf) and gtk2/gtk+2 -- no mention of gtk30.  I selected glib20, pkgconf, gtk20 and added gtk30 for good measure.

I then installed xorg, emacs24, xterm, fluxbox, firefox and finally wireshark (in that order) from ports after first running make clean && make distclean && make rmconfig-recursive in each of the folders.  In each case I accepted the default configurations.  I think this is as vanilla as it gets.

It still segfaults.

The fact that the most current README.bsd file includes references to non-existent or deprecated ports, makes me wonder if this reflects some underlying errors in the current wireshark package.

I can think of no other experiments to run.  I have been using FreeBSD since 2000.  I consider myself reasonably competent and certainly comfortable with installation of ports.  Other than an early incident with a bad printer driver, this is the first time I have been really stumped.
Comment 24 Joe Marcus Clarke freebsd_committer 2014-12-20 23:50:57 UTC
What do you make.conf and environment look like?
Comment 25 sasha 2014-12-21 02:45:37 UTC
i kept everything completely non-controversial.  I am operating under the assumption that if I do no customizing and build according to the instructions a given port should either build or complain.

/etc/make.conf has only one line WITH_PKGNG=yes

output from env is 

TERMCAP=xterm|X11 terminal emulator:@7=\EOF:@8=\EOM:F1=\E[23~:F2=\E[24~:K2=\EOE:Km=\E[M:k1=\EOP:k2=\EOQ:k3=\EOR:k4=\EOS:k5=\E[15~:k6=\E[17~:k7=\E[18~:k8=\E[19~:k9=\E[20~:k;=\E[21~:kI=\E[2~:kN=\E[6~:kP=\E[5~:kd=\EOB:kh=\EOH:kl=\EOD:kr=\EOC:ku=\EOA:am:bs:km:mi:ms:ut:xn:AX:Co#8:co#90:kn#12:li#50:pa#64:AB=\E[4%dm:AF=\E[3%dm:AL=\E[%dL:DC=\E[%dP:DL=\E[%dM:DO=\E[%dB:LE=\E[%dD:RI=\E[%dC:UP=\E[%dA:ae=\E(B:al=\E[L:as=\E(0:bl=^G:cd=\E[J:ce=\E[K:cl=\E[H\E[2J:cm=\E[%i%d;%dH:cs=\E[%i%d;%dr:ct=\E[3g:dc=\E[P:dl=\E[M:ei=\E[4l:ho=\E[H:im=\E[4h:is=\E[!p\E[?3;4l\E[4l\E>:kD=\E[3~:ke=\E[?1l\E>:ks=\E[?1h\E=:kB=\E[Z:le=^H:md=\E[1m:me=\E[m:ml=\El:mr=\E[7m:mu=\Em:nd=\E[C:op=\E[39;49m:rc=\E8:rs=\E[!p\E[?3;4l\E[4l\E>:sc=\E7:se=\E[27m:sf=^J:so=\E[7m:sr=\EM:st=\EH:ue=\E[24m:up=\E[A:us=\E[4m:ve=\E[?12l\E[?25h:vi=\E[?25l:vs=\E[?12;25h:kb=\010:
Comment 26 Joe Marcus Clarke freebsd_committer 2014-12-21 05:01:35 UTC
Then if older wireshark still crashes, you should work back the two other ports that are in this stack to see where the crash stops.  Start with gtk30 and revert to a version that was available when you had a known working version of wireshark.  If the crash still occurs go back to the latest gtk30 and revert glib20 to an older version.  It really should be one of those two ports at this point.
Comment 27 stoa 2014-12-21 23:11:44 UTC
I can't seem to NOT reproduce.  I found some spare disk space and installed 10.0-RELEASE (I've had certain other issues with the 10.1 update and patch-1, so I wanted to start from the last place I had a working Wireshark.)

Using packages only, installed pkg, xorg, dwm, dmenu, and wireshark.  No custom configuration at all.  Segfault/core dump.

If someone can provide the link to distfiles of prior versions (I can't seem to find anywhere) of gtk and glib, I'd be glad to test.
Comment 28 Joe Marcus Clarke freebsd_committer 2014-12-22 02:26:14 UTC
You should be able to simply checkout old versions of the ports through SVN or grab them from svnweb.

But that said, I think something else is at play.  What changed between when this worked and now?  Maybe something to do with X?  I use VMware.  Maybe you are using a hardware accelerated X driver that is triggering this.

I'm about at the end of what I can suggest.  Since you can reproduce and I cannot, this is quickly going to stall unless you make a breakthrough on your end.
Comment 29 sasha 2014-12-22 21:26:43 UTC
My experience is the same as yours.  I spent a lot of time using svn and reverting to several different versions of both wireshark, gtk20 and gtk30, trying out a number of different combinations.  All to no avail.  If you do find a successful combination, please post it.

I agree something else is at play.  The most significant change was an update to pkg that caused problems with X and emacs having to do with missing dependencies that were not brought in when installing binaries.  In the case of X and emacs, building from ports resolved the problem -- wireshark installs both ways without complaint, but segfaults no matter what I try.  

As an aside, despite claims to the contrary, the newest X and xorg-server do not always play nicely with newer intel GPUs.  I have had mixed success with machines in the i5 and higher series -- specifically, even using vt, exiting from X causes a black screen on some machines (but you can still type blind) and a genuine system crash on others.  That being said, I am only trying to install wireshark on i3 machines: a couple where it used to work and one that was a completely clean installation.

My other thought is that the change in the toolchain, from gcc to clang, does not yet seem to be complete.  I don't know if that might play a role.
Comment 30 stoa 2014-12-23 12:57:42 UTC
I was trying to go from the bottom-up, so to speak, in Comment 27.  I installed, from the same 10.0 disk, on a computer that I had previously been running 10.0 and where Wireshark worked.  So, I eliminated hardware as an issue.  Second, I applied no patches or updates to the base system, so I think the toolchain might be eliminated as well.

It looks like you've come from the opposite end, also to no avail.  I guess the issue is somewhere in the middle, so I'll keep looking (although, the reason I installed Wireshark in the first place, to diagnose a connection problem to portsnap and svn mirrors, I have since solved with tshark.)

I have both xorg-server-1.12 and -1.14 (since it is not working well for me either, I've only installed on one computer) and I'm not seeing that causing any differences in this matter.

In general, Joe made the comment above that he is running on VMware instead of a hardware install.  This would seem to be a huge clue, since he can't reproduce the problem and a hardware install won't seem to work in any instance, but I have zero experience with virtual machines so as to diagnose the difference in the installs.
Comment 31 Oleg Ginzburg 2014-12-23 16:50:56 UTC
The same behavior on 11.0-CURRENT/amd64:


0x0000000809ca3c0b in g_type_check_instance_is_fundamentally_a () from /usr/local/lib/libgobject-2.0.so.0

(gdb) bt
#0  0x0000000809ca3c0b in g_type_check_instance_is_fundamentally_a () from /usr/local/lib/libgobject-2.0.so.0
#1  0x0000000809c8c83b in g_object_ref () from /usr/local/lib/libgobject-2.0.so.0
#2  0x0000000809f0993d in g_list_foreach () from /usr/local/lib/libglib-2.0.so.0
#3  0x0000000808395bf3 in gtk_window_set_icon_list () from /usr/local/lib/libgtk-3.so.0
#4  0x00000000004444b6 in _start ()
#5  0x0000000809c87912 in g_closure_invoke () from /usr/local/lib/libgobject-2.0.so.0
#6  0x0000000809c9c593 in g_signal_emitv () from /usr/local/lib/libgobject-2.0.so.0
#7  0x0000000809c9d308 in g_signal_emit_valist () from /usr/local/lib/libgobject-2.0.so.0                                                                                           
#8  0x0000000809c9da24 in g_signal_emit () from /usr/local/lib/libgobject-2.0.so.0                                                                                                  
#9  0x000000080837ad14 in gtk_widget_realize () from /usr/local/lib/libgtk-3.so.0
Comment 32 Joe Marcus Clarke freebsd_committer 2014-12-23 17:05:36 UTC
Everyone needs to ask themselves, "what changed?"  Clearly wireshark, glib20, and gtk30 are not at fault directly.  Previous (working) versions now crash.

Given that the crash occurs in some icon processing, what could be related?  libpng, X, X drivers, gdk-pixbuf.  Try downgrading these in series to see what causes the issue.  Given that my wireshark doesn't crash, I'd lean toward X drivers.  Something is very environment-specific.
Comment 33 sasha 2014-12-23 18:45:31 UTC
Both stoa and I have experimented with clean installations and careful, controlled -- very vanilla -- installations of packages/ports.  By your comment 'Everyone needs to ask themselves, "what changed?"', what are you proposing?  Some direction would help.  Why do you think upgrading from 1.10.5 to 1.12.2 might result in this problem?  Personally I don't know what changed, but on my end, initially, it was only the upgrade of wireshark.  I am prepared to do a complete clean installation of BSD and then install packages according to directions you provide, but first I would like to know -- If the result is failure, what would you conclude?

The following is my original email that is not here, just so others can see the circumstances under which this problem appeared fo me.

I have wireshark (1.10.5 and 1.10.6)  installed on two machines and have never experienced any problems.

This afternoon, I tried installing the current version (1.12.2) on another machine.  The installation proceeds smoothly and without warnings.  Attempts to run the program, however, result in an immediate segmentation fault and core dump.  I have tried to install from the ports collection using portupgrade and  from binaries using pkg , but neither attempt yielded a functioning program.

I am running FreeBSD 9.3-RELEASE-p5 on all three machines.  Of the two working machines, the one running 1.10.5 is identical to the one on which I am having the installation problems.

I subsequently upgraded the other two machines and wireshark broke.
Comment 34 Joe Marcus Clarke freebsd_committer 2014-12-23 19:04:10 UTC
So you are saying that if you downgrade to wireshark 1.10.6 on a crashing machine, then it no longer crashes?

If so, that would tell me that gtk30 is the trigger.  So I would ask if you have other gtk30 apps that also crash.

If 1.10.6 now crashes, then what ELSE has changed?  Are you using newer X drivers that when wireshark was working?  What other ports on which wireshark depends have been updated?
Comment 35 sasha 2014-12-23 23:55:13 UTC
comment 23. reverting to earlier wireshark still crashes
comment 29. in response to your comment 26.
comment 29 and comment 30. regarding X and xorg-server.  I have already suggested the problem might be connected to X.

Yes, I am using a newer xorg-server, but can't/won't go back.  See
I had been using xorg-server 1.7.7_8,1 with xorg-minimal-7.5.

Would you, Joe, be willing to consider a hardware install?

I suppose I can go through the list of dependencies and then check all the involved ports to see which have been updated, but not before the weekend.  On the other hand, if we need to downgrade parts of our system to make wireshark work ...
Comment 36 sasha 2014-12-24 01:18:00 UTC
I have gotten a reversion to work, but not on a clean machine -- i.e. this is a machine on which wireshark used to work until the upgrade.

I found a wireshark package I built some time ago on my test network.  I had to ignore a complaint about missing a dependency by using pkg -M (it wanted perl5 version 5.14.4_5, but I have 5.18.4_10 installed), and I had to symlink libGeoIP.so.5 to my installed libGeoIP.so.1


tomorrow I will try upgrading that wirehark to the current with no other changes and report the results.

Please note that there are some other anomalies on this machine.  For example running pkg which <library> returns <library> was not found in the database.  Also, even though I converted to pkgng a long time ago, when I installed wireshark, I got the following message: "pkg_install EOL is scheduled for 2014-09-01. Please consider migrating to pkgng."
Comment 37 Joe Marcus Clarke freebsd_committer 2014-12-24 02:56:52 UTC
I cannot do a hardware install unless someone wants to send me hardware.  If wireshark 1.10.x works, then likely this has to do with some kind of gtk30 interaction since 1.12 introduced gtk30.  I still think X/drivers are to blame since my up-to-date machine using VMware drivers works.
Comment 38 Oleg Ginzburg 2014-12-24 13:37:30 UTC
I've also test wireshark in clean (jail) environment: create jail, pkg install wireshark, without any other packages. Set DISPLAY display and run.

Perhaps this remark related to the problem:


But I still could not find the changes leading to the problem.
Comment 39 Jimmy Olgeni freebsd_committer 2014-12-29 20:07:46 UTC
I have truss output for both cases, if anybody knows what to look for.

When installing from the same set of binary packages, it seems not to be working on VirtualBox VMs (but that doesn't mean much as I only have one actual hardware host to test.)
Comment 40 Rodrigo Osorio freebsd_committer 2014-12-29 22:39:28 UTC
same issue win my machine with a FreeBSD 10.0-RELEASE and the x64 packages up-to-date. 

My packages list is here http://www.bebik.net/poudriere/patches/listofpkg.txt
Comment 41 sasha 2014-12-29 23:55:17 UTC
I have gotten a second instance of wireshark-1.10.6 to work on a different machine.  As before, see comment 36, I had to use pkg add -M wireshark-1.10.6.txz and do a fair amount of symlinking.  If you try this method, keep in mind that it is just a lousy hack on a broken port for testing purposes.  If you use pkg instead of portupgrade/portmaster to perform upgrades, pkg will force you to deinstall wireshark next time you perform upgrades.  If you haven't saved a copy of wireshark-1.10.6.txz somewhere outside of /var/cache/pkg you will need to find a new copy.

Olevole, the link you give in comment 38 links to one of the files I mention in my comment 23. Notice there is NO mention of gtk3 even though those are the most recent readme files that go with the wireshark port.

Assuming, at this point, that the problem is related to gtk3, where do we go from here?  Is it a gtk problem or a problem with the way wireshark is using gtk?  Any new ideas Joe?
Comment 42 stoa 2014-12-30 02:13:52 UTC
I can confirm the same issue presented here also occurs on the i386 architecture on a new install of 10.0-RELEASE.
Comment 43 Oleg Ginzburg 2014-12-30 07:39:14 UTC
Yes, looks like it is GTK3 issue. I build wireshark-qt ( patch is incomplete due to we need mv wireskark-qt to wireshark in STAGE dir )

Nevertheless, wireshark with qt works where not working gtk:

root@gizmo:/usr/ports/net # diff -ruN wireshark.bak wireshark 
diff -ruN wireshark.bak/Makefile wireshark/Makefile
--- wireshark.bak/Makefile      2014-12-24 18:58:49.000000000 +0300
+++ wireshark/Makefile  2014-12-30 10:20:19.000000000 +0300
@@ -51,7 +51,11 @@
 .if !defined(LITE)
                        GNUTLS GCRYPT THREADS
 RTP_DESC=              Enable support for playing back RTP streams
 ADNS_DESC=             Enable asynchronous DNS lookup support
@@ -67,8 +71,6 @@
-USE_GNOME+=    gtk30
 PLIST_SUB+=    WIRESHARK="@comment wireshark not built" \
                WIRESHARK_MAN="@comment wireshark not built "
@@ -77,6 +79,20 @@
+USE_GNOME+=            gtk30
+CONFIGURE_ARGS+=       --with-gtk2=no \
+                       --with-gtk3=yes \
+                       --with-qt=no
+CONFIGURE_ARGS+=       --with-gtk2=no \
+                       --with-gtk3=no \
+                       --with-qt=yes
+USE_QT5+=              core widgets printsupport buildtools_build
Comment 44 stoa 2014-12-30 12:51:33 UTC
I built wireshark-qt on Gentoo some time ago and it worked well.  It's not a real concern, but there was a marked difference in the gui-available information, i.e., the graphics were very spartan compared to the gtk+ version.  It looks like, from your screenshot, this is still the case?
Comment 45 Joe Marcus Clarke freebsd_committer 2014-12-30 17:18:50 UTC
Can you guys try patching the Makefile with this to see if it fixes the problem:

--- /usr/ports/net/wireshark/Makefile   2014-11-13 15:54:19.000000000 -0500
+++ Makefile    2014-12-30 12:08:59.937476360 -0500
@@ -163,6 +163,7 @@ CONFIGURE_ARGS+=--with-krb5=no
        @${REINPLACE_CMD} -e 's|llua|llua-${LUA_VER}|g ; \
+               s|-DGDK_PIXBUF_DISABLE_DEPRECATED||g ; \
                s|-Wl,--as-needed|| ' \
Comment 46 Jimmy Olgeni freebsd_committer 2014-12-30 17:56:36 UTC
(In reply to Joe Marcus Clarke from comment #45)

> Can you guys try patching the Makefile with this to see if it fixes the
> problem:

Works for me - I got wireshark back. Thanks!
Comment 47 commit-hook freebsd_committer 2014-12-30 18:00:25 UTC
A commit references this bug:

Author: marcus
Date: Tue Dec 30 18:00:08 UTC 2014
New revision: 375839
URL: https://svnweb.freebsd.org/changeset/ports/375839

  Fix a crash due to a truncated pointer.

  PR:		195980

Comment 48 Joe Marcus Clarke freebsd_committer 2014-12-30 18:00:52 UTC
Fixed in 1.12.2_1.
Comment 49 stoa 2014-12-30 18:33:40 UTC
Yes - the patch works.  But then, you already know that....

Thanks, Joe (and to everybody who helped out here.)
Comment 50 Rodrigo Osorio freebsd_committer 2014-12-30 18:47:57 UTC
works for me too !
Comment 51 sasha 2014-12-31 00:52:09 UTC
wireshark works for me too, but with many missing icons -- the functionality is normal though.
Comment 52 sasha 2014-12-31 01:29:21 UTC
I just needed to add the adwaita-icon-theme.  All sorted.
Comment 53 Oleg Ginzburg 2014-12-31 10:26:03 UTC
it works, thx