Hello everyone! I'm fairly new to using gtk and c and I have a question regarding changing the color of pixels. So I have an image file I read it and do some calculations using the pixel data which I access doing this:

The strange thing is that the image appears on my Desktop and the pixels are colored like it should but my program crashes.If I comment this part out:

Code:

p[0]=50;p[1]=0;p[2]=0;

Then the program never crashes.

So my question is, is it fine the way I am coloring the pixels or should I do it another way? Apparently the program doesn't like the way I color the pixels since that's the only part that causes it to crash.

hmmm.Well you pretty much did it just like the documentation, except minor stuff like g_assert for checking things are the right format which you would know anyway.you might need to cast your 0, 50 etc to guchar, e.g.p[0]=(guchar)50;*(p+1)=(guchar)0;Also when debugging it helps to include the GError and have a look what it might say.If you run it through gdb and set breakpoints you can determine whether its crashing as a result of the p[0]=50 or when you try to save.

Thanks Paul! I don't have the code right now but I forgot to specify that the program compiles without a problem and saves the image which is the last thing it does. Just after saving the image it crashes but only if I changed the pixels before. I'll try casting the numbers to guchar like you suggested and posting the error tomorrow when I get to the lab. Thanks for the help!

hmm that's the kind of error you get when trying to debug something, but I don't know what would be trying to debug glib or why.Try doing a debug with gdb to debugcompile with the -g flag incuded then typegdb nameofprogramr (to run)bt (to get the trace when things go wrong -- you can omit the 0x.. hex values as they are memory addresses that will be different on every system)Might also help t post or send a link of your code

I kind of figured it was a segmentation fault but now I have to figure out why it is happening there. This is the trace.

Code:

#0 0x0804b789 in computar_transformadas (widget=0x809c490, event=0x807ae48, callback_data=0x0) at ../Principal/Menu.c:612#1 0xb7b6e662 in ?? () from /usr/lib/i386-linux-gnu/libgtk-x11-2.0.so.0#2 0xb756b3dc in g_closure_invoke () from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0#3 0xb757e180 in ?? () from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0#4 0xb7586d29 in g_signal_emit_valist () from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0#5 0xb7587083 in g_signal_emit () from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0#6 0xb7ca6fe3 in ?? () from /usr/lib/i386-linux-gnu/libgtk-x11-2.0.so.0#7 0xb7b6c81e in gtk_propagate_event () from /usr/lib/i386-linux-gnu/libgtk-x11-2.0.so.0#8 0xb7b6ce88 in gtk_main_do_event () from /usr/lib/i386-linux-gnu/libgtk-x11-2.0.so.0#9 0xb79d3d08 in ?? () from /usr/lib/i386-linux-gnu/libgdk-x11-2.0.so.0#10 0xb7495a3f in g_main_context_dispatch () from /lib/i386-linux-gnu/libglib-2.0.so.0#11 0xb7496170 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0#12 0xb749677b in g_main_loop_run () from /lib/i386-linux-gnu/libglib-2.0.so.0#13 0xb7b6b94f in gtk_main () from /usr/lib/i386-linux-gnu/libgtk-x11-2.0.so.0#14 0x080491ee in main (argc=1, argv=0xbffff3c4) at ../Principal/Menu.c:80

Well it's saying that its crashing at line 612 which isn't the region of code I imagine that has anything to do with saing the data, so I think the way your editing the image is fine its just that there is a bug elsewhere in your code that wasn't noticed until the image editing step came along. Most likely something has changed to par.prueba (or limits on phi or j) that it could no longer access [phi][j][1]. (maybe when the buffer was saved to file something got turned to a null pointer or freed?)If you can't pin it down, you could either set breakpoints here to figure out what the allocated size of it is (along with the current j and phi) or print out a message for you to see.

Well it's saying that its crashing at line 612 which isn't the region of code I imagine that has anything to do with saing the data, so I think the way your editing the image is fine its just that there is a bug elsewhere in your code that wasn't noticed until the image editing step came along. Most likely something has changed to par.prueba (or limits on phi or j) that it could no longer access [phi][j][1]. (maybe when the buffer was saved to file something got turned to a null pointer or freed?)If you can't pin it down, you could either set breakpoints here to figure out what the allocated size of it is (along with the current j and phi) or print out a message for you to see.

Sorry for taking so long to write back. You're right, it appears I'm having memory allocation problems. I use malloc a lot because I need multidimensional arrays created dynamically but, after using valgrind, there are a lot of errors... Well now I must search what my problem is elsewhere but anyways, thanks for the help Paul :)

glib (which is wrapped in with gtk) has a lot of dynamically allocated data structures available (http://developer.gnome.org/glib/stable/glib-data-types.html). It takes care of most of the dynamic allocation issues (no need to call malloc) and is more compatible with gtks ethos of reference counting (might be wht went wrong). You still need to free up the memory when done (using glibs own functions for that).

Who is online

Users browsing this forum: Google [Bot] and 3 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum