gtk+ cairo --> segmentation fault

[LoTeK]

hi,
Although this forum is also about basic programming questions, I'm not sure if my question is either basic enough or to far away from gentoo or the C core language, but anyway I'll ask

I've written a program that displays the power usage, temperature and charge status of my battery and if AC is online or not (through pictures), and it works fine but after maybe 5 mins the program suddenly crashes with "Segmentation fault" to stderr.
I think "segmentation fault" means that the program tries to access some parts of the RAM that it isn't allowed to?! but because the program runs correct for few minutes I don't know where my fault could be...

here is my code:
http://bpaste.net/show/71273

btw, I also think that it's rather poorly coded (I'm new to graphic-programming), so if anyone has suggestions to program anything better although it's not connected to the problem I'm happy to read from you...

[derk]

static gboolean time_handler (GtkWidget *widget)
{
if (widget == NULL)
return FALSE;
# I think your problem is here
# do the fopen (s) once only to get the handle (s) then you do the fscanf on the same handle when you need fresh data
# other wise I think you run out of file handles especially as you over write them without releasing them (i.e. fclose) thus crash
# file handles are a finite system resource :^)

power_file = fopen ("/sys/devices/platform/smapi/BAT0/power_now", "r");
fscanf (power_file, "%i", &power);

perc_file = fopen ("/sys/devices/platform/smapi/BAT0/remaining_percent", "r");
fscanf (perc_file, "%i", &perc);

temp_file = fopen ("/sys/devices/platform/smapi/BAT0/temperature", "r");
fscanf (temp_file, "%i", &temp);

update_squares (power);
update_temp (temp);
update_perc (perc);

gtk_widget_queue_draw (widget);
return TRUE;
}

[VoidMage]

While the above might be a reason too (as you're leaking the descriptors right and left), there's one other thing.

In gtk3, for the widgets you're using, you shouldn't use gdk_cairo_create...cairo_destroy in 'draw' callbacks.
You're getting the context as a parameter and it must not be destroyed.

On a not quite related note, is there any point of using GtkFixed here ?

[wcg]

The other comments aside, what is a segfault? It is writing into
address space not allocated to your program. You can get it by
somehow corrupting an address assigned to a variable, then
writing to that variable, or by simply overrunning a buffer that
is close enough to a boundary of space allocated to your program
that the write extends into something else's address space
or into unallocated address space (either way, the kernel
knows this address space is not allocated to your process).

That could happen due to a bug in gtk or in some other
shared library that your process calls, but more commonly
the bug is in your own code.

If you can start the process from a terminal window, you
can use gdb in that terminal window to start the process
and get a backtrace of the sequence of function calls
with their arguments that leads to the segfault.

http://www.gentoo.org/proj/en/qa/backtraces.xml

(Recompiling the system with -ggdb in CFLAGS and
FEATURES=splitdebug in /etc/portage/make.conf
will get you better information from gdb. Typically
the only cost is disk space for the debug information
from programs and libraries.)
_________________
TIA

[VoidMage]

Regarding above: while usually it only costs disk space, sometimes it costs a lot of it - i.e. in cases like firefox, it's (IRC) about 8x the size and in the case of webkit-gtk, the memory/disk space consumption during build is a bit crazy.

[LoTeK]

[VoidMage]

Looks like that guide is simply not quite correct - unless you're using widgets like GtkLayout (which beside its standard GdkWindow has another for the scrolled content (_get_bin_window)), the only context that matters (besides the ones you want to create) is the one you get in that callback parameter.
As for the other question: 'man fopen', 'man fclose'.

Regarding GtkFixed: use a GtkGrid then; GtkFixed is really not a good idea.

[BillWho]

[wcg]

[LoTeK]

[VoidMage]

[wcg]

[wcg]

PS: You can get a complete dependency tree for a package that
portage knows about (has an ebuild for) with equery, part of
the gentoolkit package:
[code]
equery g --depth=0 packagename
[/code]
_________________
TIA