Re: g_ptr_array_sort crash
you were right, the compare function was to blame. the error happened because two integers that were the same weren't the same after some transformations to float, so the function didn't return 0, as it should have. a nasty bug, that one. gyözö > This might be happening because your compare function is inconsistent, > e.g. when > >player_compare_func (foo, bar, x) returns a value < 0 > and >player_compare_func (bar, foo, x) returns 0 (instead of a value > >0) > > or >player_compare_func (bar, bar, x) returns a value != 0 (instead >of 0) > > or something similar. > > Cheers > -Tim > -- Just because your doctor has a name for your condition doesn't mean he knows what it is. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: g_ptr_array_sort crash
On Sun, Feb 13, 2005 at 12:30:07PM +0100, Gyözö Both wrote: > this is the valgrind output (with tool memcheck): > > ==6098== Invalid read of size 4 > ==6098==at 0x807AC54: player_compare_func (player.c:393) > > ... > > doesn't help me a lot :-( > > > Try valgrind, because this looks like consequences of > > a memory problem that occurs elsewhere. There are two > > common problems it may not catch: overwritten stack and > > wrong level of indirection (i.e., you used too much &'s > > somewhere), but chances are it will find that `elsewhere'. Well, I suppose lines 393-394 and 404 are those where it crashes `normally', so we've gained no info. A bug in g_ptr_array_sort() is highly improbable (it's a tested copy of well-tested glib'c qsort()) so what remains is to debug your code the hard way. If the array is ok before sort starts, something must modify it during that. You can even print complete array after each compare or whatever, but the problem is to find where you corrupt the data, GLib has little to do with it. Yeti -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: g_ptr_array_sort crash
On Sunday 13 February 2005 08:06, Gyözö Both wrote: > i'm sorting a pointer array and every once in a while i get a segfault. > i'm checking the pointers before sorting with > g_ptr_array_sort_with_data, and they are fine. the data i pass, an > integer (with GINT_TO_POINTER) is also all right. > > the crash happens in the compare function, which looks like this: > (snip) > > i print out the two pointers pl1 and pl2, and mostly they are fine, but > sometimes one of them looks weird (0x049) and is obviously invalid, so > i get a segfault when the function tries to access the struct members. > > as i said, the pointers in the array are all valid and ok before i call > g_ptr_array_sort. > > i don't have a clue what the problem could be :-( hope you have ideas. This might be happening because your compare function is inconsistent, e.g. when player_compare_func (foo, bar, x) returns a value < 0 and player_compare_func (bar, foo, x) returns 0 (instead of a value > 0) or player_compare_func (bar, bar, x) returns a value != 0 (instead of 0) or something similar. Cheers -Tim ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: g_ptr_array_sort crash
this is the valgrind output (with tool memcheck): ==6098== Invalid read of size 4 ==6098==at 0x807AC54: player_compare_func (player.c:393) ==6098==by 0x1BD7504D: g_qsort_with_data (in /opt/gnome/lib/libglib-2.0.so.0 .400.6) ==6098==by 0x1BD50B40: g_ptr_array_sort_with_data (in /opt/gnome/lib/libglib -2.0.so.0.400.6) ==6098==by 0x805BF3A: game_get_penalty_taker (game.c:200) ==6098== Address 0x9C61DD78 is not stack'd, malloc'd or (recently) free'd ==6098== ==6098== Process terminating with default action of signal 11 (SIGSEGV) ==6098==at 0x807AC54: player_compare_func (player.c:393) ==6098==by 0x1BD7504D: g_qsort_with_data (in /opt/gnome/lib/libglib-2.0.so.0 .400.6) ==6098==by 0x1BD50B40: g_ptr_array_sort_with_data (in /opt/gnome/lib/libglib -2.0.so.0.400.6) ==6098==by 0x805BF3A: game_get_penalty_taker (game.c:200) and this with corecheck: ==6123== Process terminating with default action of signal 11 (SIGSEGV) ==6123== Access not within mapped region at address 0x881C1614 ==6123==at 0x807AC54: player_compare_func (player.c:393) ==6123==by 0x3ADEF04D: g_qsort_with_data (in /opt/gnome/lib/libglib-2.0.so.0.400.6) ==6123==by 0x3ADCAB40: g_ptr_array_sort_with_data (in /opt/gnome/lib/libglib-2.0.so.0.400.6) ==6123==by 0x805BF3A: game_get_penalty_taker (game.c:200) and addrcheck: ==6138== Invalid read of size 4 ==6138==at 0x807AC52: player_compare_func (player.c:394) ==6138==by 0x345BAE9B: g_qsort_with_data (in /opt/gnome/lib/libglib-2.0.so.0.400.6) ==6138==by 0x34596B40: g_ptr_array_sort_with_data (in /opt/gnome/lib/libglib-2.0.so.0.400.6) ==6138==by 0x805BF3A: game_get_penalty_taker (game.c:200) ==6138== Address 0x34E79174 is 4 bytes before a block of size 64 alloc'd ==6138== at 0x341492F4: malloc (in /usr/lib/valgrind/vgpreload_addrcheck.so) ==6138==by 0x34149CF7: realloc (in /usr/lib/valgrind/vgpreload_addrcheck.so) ==6138==by 0x345B4C10: g_realloc (in /opt/gnome/lib/libglib-2.0.so.0.400.6) ==6138==by 0x34596E17: g_ptr_array_maybe_expand (in /opt/gnome/lib/libglib-2.0.so.0.400.6) ==6138== ==6138== Invalid read of size 4 ==6138==at 0x807ACAA: player_compare_func (player.c:404) ==6138==by 0x345BAE9B: g_qsort_with_data (in /opt/gnome/lib/libglib-2.0.so.0.400.6) ==6138==by 0x34596B40: g_ptr_array_sort_with_data (in /opt/gnome/lib/libglib-2.0.so.0.400.6) ==6138==by 0x805BF3A: game_get_penalty_taker (game.c:200) ==6138== Address 0xF is not stack'd, malloc'd or (recently) free'd ==6138== ==6138== Process terminating with default action of signal 11 (SIGSEGV) ==6138== Access not within mapped region at address 0xF ==6138==at 0x807ACAA: player_compare_func (player.c:404) ==6138==by 0x345BAE9B: g_qsort_with_data (in /opt/gnome/lib/libglib-2.0.so.0.400.6) ==6138==by 0x34596B40: g_ptr_array_sort_with_data (in /opt/gnome/lib/libglib-2.0.so.0.400.6) ==6138==by 0x805BF3A: game_get_penalty_taker (game.c:200) doesn't help me a lot :-( gyözö > On Sun, Feb 13, 2005 at 09:06:50AM +0100, Gyözö Both wrote: > > i'm sorting a pointer array and every once in a while i get a > > segfault. i'm checking the pointers before sorting with > > g_ptr_array_sort_with_data, and they are fine. the data i pass, an > > integer (with GINT_TO_POINTER) is also all right. > > > > ... > > > > i print out the two pointers pl1 and pl2, and mostly they are fine, > > but sometimes one of them looks weird (0x049) and is obviously > > invalid, so i get a segfault when the function tries to access the > > struct members. > > > > as i said, the pointers in the array are all valid and ok before i > > call g_ptr_array_sort. > > Try valgrind, because this looks like consequences of > a memory problem that occurs elsewhere. There are two > common problems it may not catch: overwritten stack and > wrong level of indirection (i.e., you used too much &'s > somewhere), but chances are it will find that `elsewhere'. > > Yeti > > > -- > A: Because it messes up the order in which people normally read text. > Q: Why is top-posting such a bad thing? > A: Top-posting. > Q: What is the most annoying thing on usenet and in e-mail? > -- I went to the race track once and bet on a horse that was so good that it took seven others to beat him! ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: g_ptr_array_sort crash
On Sun, Feb 13, 2005 at 09:06:50AM +0100, Gyözö Both wrote: > i'm sorting a pointer array and every once in a while i get a segfault. > i'm checking the pointers before sorting with > g_ptr_array_sort_with_data, and they are fine. the data i pass, an > integer (with GINT_TO_POINTER) is also all right. > > ... > > i print out the two pointers pl1 and pl2, and mostly they are fine, but > sometimes one of them looks weird (0x049) and is obviously invalid, so > i get a segfault when the function tries to access the struct members. > > as i said, the pointers in the array are all valid and ok before i call > g_ptr_array_sort. Try valgrind, because this looks like consequences of a memory problem that occurs elsewhere. There are two common problems it may not catch: overwritten stack and wrong level of indirection (i.e., you used too much &'s somewhere), but chances are it will find that `elsewhere'. Yeti -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
g_ptr_array_sort crash
hi,
i'm sorting a pointer array and every once in a while i get a segfault.
i'm checking the pointers before sorting with
g_ptr_array_sort_with_data, and they are fine. the data i pass, an
integer (with GINT_TO_POINTER) is also all right.
the crash happens in the compare function, which looks like this:
gint
player_compare_func(gconstpointer a, gconstpointer b, gpointer data)
{
const Player *pl1 = *(const Player**)a;
const Player *pl2 = *(const Player**)b;
gint type = GPOINTER_TO_INT(data);
(compare the structs that are pointed to)
}
i print out the two pointers pl1 and pl2, and mostly they are fine, but
sometimes one of them looks weird (0x049) and is obviously invalid, so
i get a segfault when the function tries to access the struct members.
as i said, the pointers in the array are all valid and ok before i call
g_ptr_array_sort.
i don't have a clue what the problem could be :-( hope you have ideas.
gyözö
--
No violence, gentlemen -- no violence, I beg of you! Consider
the furniture!
-- Sherlock Holmes
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
