GTK+ Programs are crashing while wmaker is running

TerryP

Howard Goldstein wrote:

> Oh for the coredumps, just gdb pooo.core
> A 'bt' will get you the backtrace and you'll see where it took a dump
>
> Sometimes you can see what's up without having symbols but sometimes
> you just gotta have built the offending apps with symbols for this to
> do any good.

Actually the problem is trying to get a core file to run GDB on ;-)

I haven't been able to find it online and recompiling the basic GTK program
with full debugging symbols (-ggdb3) doesn't get it to dump core. Just
running it in GDB does show a crash pretty darn fast though:

Terry@Dixie$ gdb helloworld
22:27
GNU gdb 6.1.1 [FreeBSD]
..... copyright stuff
(gdb) break 1
Breakpoint 1 at 0x8048994: file helloworld.c, line 1.
(gdb) run
Starting program: /usr/home/Terry/code/oldstuff/GTK/helloworld
warning: Unable to get location for thread creation breakpoint: generic
error
[New LWP 100113]
[New Thread 0x8053000 (LWP 100113)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x8053000 (LWP 100078)]
0x288e4724 in setenv () from /lib/libc.so.6
(gdb) bt

http://pastebin.ca/803137 # backtrace and source

(gdb) generate-core-file
Saved corefile core.95336

No clue if it's the proper way to get one but hey I guess it's a core file
^_^

--
Such evil deeds could religion prompt.
-- Titus Lucretius Carus

TerryP

Howard Goldstein wrote:

> Oh for the coredumps, just gdb pooo.core
> A 'bt' will get you the backtrace and you'll see where it took a dump
>
> Sometimes you can see what's up without having symbols but sometimes
> you just gotta have built the offending apps with symbols for this to
> do any good.

Actually the problem is trying to get a core file to run GDB on ;-)

I haven't been able to find it online and recompiling the basic GTK program
with full debugging symbols (-ggdb3) doesn't get it to dump core. Just
running it in GDB does show a crash pretty darn fast though:

Terry@Dixie$ gdb helloworld
22:27
GNU gdb 6.1.1 [FreeBSD]
..... copyright stuff
(gdb) break 1
Breakpoint 1 at 0x8048994: file helloworld.c, line 1.
(gdb) run
Starting program: /usr/home/Terry/code/oldstuff/GTK/helloworld
warning: Unable to get location for thread creation breakpoint: generic
error
[New LWP 100113]
[New Thread 0x8053000 (LWP 100113)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x8053000 (LWP 100078)]
0x288e4724 in setenv () from /lib/libc.so.6
(gdb) bt

http://pastebin.ca/803137 # backtrace and source

(gdb) generate-core-file
Saved corefile core.95336

No clue if it's the proper way to get one but hey I guess it's a core file
^_^

--
Such evil deeds could religion prompt.
-- Titus Lucretius Carus

TerryP

Howard Goldstein wrote:

> Oh for the coredumps, just gdb pooo.core
> A 'bt' will get you the backtrace and you'll see where it took a dump
>
> Sometimes you can see what's up without having symbols but sometimes
> you just gotta have built the offending apps with symbols for this to
> do any good.

Actually the problem is trying to get a core file to run GDB on ;-)

I haven't been able to find it online and recompiling the basic GTK program
with full debugging symbols (-ggdb3) doesn't get it to dump core. Just
running it in GDB does show a crash pretty darn fast though:

Terry@Dixie$ gdb helloworld
22:27
GNU gdb 6.1.1 [FreeBSD]
..... copyright stuff
(gdb) break 1
Breakpoint 1 at 0x8048994: file helloworld.c, line 1.
(gdb) run
Starting program: /usr/home/Terry/code/oldstuff/GTK/helloworld
warning: Unable to get location for thread creation breakpoint: generic
error
[New LWP 100113]
[New Thread 0x8053000 (LWP 100113)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x8053000 (LWP 100078)]
0x288e4724 in setenv () from /lib/libc.so.6
(gdb) bt

http://pastebin.ca/803137 # backtrace and source

(gdb) generate-core-file
Saved corefile core.95336

No clue if it's the proper way to get one but hey I guess it's a core file
^_^

--
Such evil deeds could religion prompt.
-- Titus Lucretius Carus

Patrick Lamaizière

TerryP wrote:

> When I attempt to run any GTK+ program while Window Maker is
> running the GTK+ program bombs out like so,
>
> Terry@Dixie$ gvim
> 21:32
> Gtk-Qt theme engine warning:
> Could not open /proc/3769/cmdline
> This may cause problems for the GNOME window manager

The port gtk-qt-engine crashs if you don't run KDE.

Patrick Lamaizière

TerryP wrote:

> When I attempt to run any GTK+ program while Window Maker is
> running the GTK+ program bombs out like so,
>
> Terry@Dixie$ gvim
> 21:32
> Gtk-Qt theme engine warning:
> Could not open /proc/3769/cmdline
> This may cause problems for the GNOME window manager

The port gtk-qt-engine crashs if you don't run KDE.

Patrick Lamaizière

TerryP wrote:

> When I attempt to run any GTK+ program while Window Maker is
> running the GTK+ program bombs out like so,
>
> Terry@Dixie$ gvim
> 21:32
> Gtk-Qt theme engine warning:
> Could not open /proc/3769/cmdline
> This may cause problems for the GNOME window manager

The port gtk-qt-engine crashs if you don't run KDE.

Patrick Lamaizière

Ashish Shukla wrote:

> It seems, your GTK+ apps are trying to access /proc filesystem, which
> is not mounted by default in FreeBSD. So looks like your GTK+ apps are
> assuming they're running on GNU/Linux. Have you installed these GTK+ apps
> - From FreeBSD ports, hmm... ?

This is only a warning from the gtk-qt-engine. I've sent a patch to the
author that use the libkvm instead of procfs.
I don't know why but gtk-qt-engine always crashs if you don't run KDE.

Patrick Lamaizière

Ashish Shukla wrote:

> It seems, your GTK+ apps are trying to access /proc filesystem, which
> is not mounted by default in FreeBSD. So looks like your GTK+ apps are
> assuming they're running on GNU/Linux. Have you installed these GTK+ apps
> - From FreeBSD ports, hmm... ?

This is only a warning from the gtk-qt-engine. I've sent a patch to the
author that use the libkvm instead of procfs.
I don't know why but gtk-qt-engine always crashs if you don't run KDE.

Patrick Lamaizière

Ashish Shukla wrote:

> It seems, your GTK+ apps are trying to access /proc filesystem, which
> is not mounted by default in FreeBSD. So looks like your GTK+ apps are
> assuming they're running on GNU/Linux. Have you installed these GTK+ apps
> - From FreeBSD ports, hmm... ?

This is only a warning from the gtk-qt-engine. I've sent a patch to the
author that use the libkvm instead of procfs.
I don't know why but gtk-qt-engine always crashs if you don't run KDE.

Howard Goldstein

On Thu, 29 Nov 2007 10:08:23 -0500, TerryP <codemonkey@nowhere.org> wrote:
: Howard Goldstein wrote:
:
: > On Wed, 28 Nov 2007 01:30:46 -0500, TerryP <codemonkey@nowhere.org> wrote:
: > : Vim, was compiled from source -- the editors/vim port was broken when
: > : I set up one of my systems last year and I have built Vim from source
: > : ever since on all but Windows.
: > :
: > : GNU Emacs may have been from ports or packages I am not sure really.
: > : It's just installed so it is available not because I use it :\
: > :
: > : The third program is from a tutorial and was compiled with this
: > : makefile
: >
: > Without a core backtrace you're not going to be able to figure out
: > what's causing the segfault. In the handbook it talks about using gdb
: > to get a backtrace, that wll narrow it down significantly.
: >
: > Failing that, do you have all of the daemons running that gnome wants?
: > (nb., I'm not a gnome or kde or qt person) Is your ports tree up to
: > date? It's gonna take forever to do on a laptop but why not go ahead
: > and rebuild everything gvim depends including gvim and see if that
: > fixes the broken bits. An invocation like
: >
: > portupgrade -fR gvim gvim
: >
: > after csupping a refreshed ports tree may get you up and running if
: > there are older ports laying about that are getting in your way and
: > you don't want to dig into the coredump or place the query over at the
: > freebsd-gnome@ mailing list
:
:
: I've never worked with corefiles before but I'll look into it, GDB is easy
: to use so it shouldn't be a problem. I'll check the handbook & google for
: more info when I get home from errands today.
:
:
: The only deamons running should be all of these but xpt_thrd;
:
: Terry@Dixie$ ps -auxc|egrep '.*d$'
: 14:58
: root 9 0.0 0.0 0 8 ?? DL 2:44PM 0:00.00 xpt_thrd
: root 786 0.0 0.1 528 380 ?? Ss 2:44PM 0:00.00 devd
: root 912 0.0 0.2 1404 1072 ?? Ss 2:44PM 0:00.01 syslogd
: root 1039 0.0 0.6 4196 2544 ?? Is 2:44PM 0:00.01 cupsd
: root 1058 0.0 0.7 5192 3080 ?? Ss 2:44PM 0:00.01 nmbd
: root 1062 0.0 1.2 8924 5532 ?? Is 2:44PM 0:00.01 smbd
: root 1077 0.0 1.2 8924 5524 ?? I 2:44PM 0:00.00 smbd
: root 1078 0.0 0.5 3664 2268 ?? Is 2:44PM 0:00.00 polkitd
: root 1089 0.0 0.2 1296 828 ?? Is 2:44PM 0:00.00 usbd
: haldaemon 1096 0.0 0.8 4776 3624 ?? Ss 2:44PM 0:00.81 hald
: root 1165 0.0 0.4 3008 1844 ?? Ss 2:44PM 0:00.03 ntpd
: root 1227 0.0 0.6 3532 2688 ?? Is 2:44PM 0:00.00 sshd
: root 1275 0.0 0.2 1436 880 ?? Ss 2:44PM 0:00.17 moused
: Terry 3410 0.0 1.8 10544 8052 ?? S 2:50PM 0:00.96 artsd
:
: And this is mostly in line with my rc.confo
:
: I am not a gnome person so I wouldn't know what daemons they expect, Vim was
: complied with support for gtk2 but not gnome and I can see how I configured
: it in vims :version output. Nore was the GTK+ test app complied with any
: thing more Gnome'ish then any generic GTK+ app. And emacs should not have
: been unless ports is getting drunk ;-)

That makes the two of us not being gnome people. That can't be good.
Xemacs used to have some weird dependencies including dependencies on
XFree86 elements even though it wasn't built with X support; I commiserate.

:
:
: My last csup of the ports tree was 2007-11-20 in the wee hours of the UTC
: morning fyi.


Yeah I'm not sure what to suggest. The tree is supposed to still be
frozen but in actuality it's only partially frozen. When I run into
issues like you're seeing with gnome I preemptively surrender and and
rebuild the dependies upwards but that might be taking out the
mosquito with the shotgun if you know what I mean.