After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 140545 - Program exits with: velena: Could not find a good OR child!
Program exits with: velena: Could not find a good OR child!
Status: RESOLVED FIXED
Product: gnome-games-superseded
Classification: Deprecated
Component: gnect
unspecified
Other Linux
: Normal critical
: ---
Assigned To: GNOME Games maintainers
GNOME Games maintainers
: 154480 170965 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2004-04-19 21:04 UTC by Stephen Isaac
Modified: 2005-04-21 07:37 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
Fix for bug #140545, using glib. (1.27 KB, patch)
2004-08-27 20:10 UTC, Richard Hoelscher 		none Details | Review

Description Stephen Isaac 2004-04-19 21:04:06 UTC 
My first every bug report!

Description of Problem:
Halfway through playing a game the program
terminates unexpectedly. When running from the
console, the text "velena: Could not find a good
OR child!" is printed to the shell on termination.
This happens approximately every other game. 

Steps to reproduce the problem:
1. Select new game
2. Play game

Actual Results:
Program terminates as above.

Expected Results:
Program does not terminate

How often does this happen? 
Every other game more or less

Additional Information:
Version 2.6.0.1 of gnect on AMD64 with Gnome 2.6
and Linux kernel-2.6.5-gentoo (Gentoo distribution).
Comment 1 Stephen Isaac 2004-04-20 20:38:08 UTC 
Also get "Could not find a good AND child!" exception aswell. 

This happens for both root and a normal user. This happens with optimisation of
-O3 and without optimisation.

PS. Have an Athlon 64 3200+ with 1GB Ram.
Player 1 Red is Human, Player 2 Yellow is Level One, Classic theme.

Hopefully have done this bit right. Have built the source without optimisation
and generated the following stack trace (broke on the line where it prints the
AND child exception.

+ Trace 46227

  • #0 her_select_most_proving_node
    at heurist.c line 290
  • #1 her_pn_search
    at heurist.c line 455
  • #2 heuristic_play_best
    at heurist.c line 571
  • #3 look_ahed
    at ia_main.c line 766
  • #4 ia_compute_move
    at ia_main.c line 1117
  • #5 playgame
    at playgame.c line 96
  • #6 process_move
    at main.c line 1077
  • #7 on_drawarea_event
    at main.c line 1140
  • #8 _gtk_marshal_BOOLEAN__BOXED
    from /usr/lib/libgtk-x11-2.0.so.0
  • #9 g_closure_invoke
    from /usr/lib/libgobject-2.0.so.0
  • #10 g_signal_emit_by_name
    from /usr/lib/libgobject-2.0.so.0
  • #11 g_signal_emit_valist
    from /usr/lib/libgobject-2.0.so.0
  • #12 g_signal_emit
    from /usr/lib/libgobject-2.0.so.0
  • #13 gtk_widget_send_expose
    from /usr/lib/libgtk-x11-2.0.so.0
  • #14 gtk_propagate_event
    from /usr/lib/libgtk-x11-2.0.so.0
  • #15 gtk_main_do_event
    from /usr/lib/libgtk-x11-2.0.so.0
  • #16 _gdk_events_queue
    from /usr/lib/libgdk-x11-2.0.so.0
  • #17 g_main_depth
    from /usr/lib/libglib-2.0.so.0
  • #18 g_main_context_dispatch
    from /usr/lib/libglib-2.0.so.0
  • #19 g_main_context_dispatch
    from /usr/lib/libglib-2.0.so.0
  • #20 g_main_loop_run
    from /usr/lib/libglib-2.0.so.0
  • #21 gtk_main
    from /usr/lib/libgtk-x11-2.0.so.0
  • #22 main
    at main.c line 1284 






Comment 2


Callum McKenzie





          2004-04-21 09:38:53 UTC
        



You've done a good job of providing the information I need. This may take a
while to track down though, I suspect it's a 64-bit problem, while I have a
64-bit machine (a ppc970) my GNOME setup is currently 32-bit so I'll have to get
the 64-bit tool-chain going.







Comment 3


Richard Hoelscher





          2004-05-17 22:50:34 UTC
        



I can confirm this on my system too, AMD64, Gentoo /w gnome-games 2.6 or 2.4 .






Comment 4


Richard Hoelscher





          2004-08-27 20:10:12 UTC
        



Created attachment 31030 [details] [review]
Fix for bug #140545, using glib.

Fixes a problem where "long" was assumed to be a 32 bit integer, not 64 bits...






Comment 5


Richard Hoelscher





          2004-08-27 20:33:36 UTC
        



Kept digging, it may be more pure for that file to use C99's <inttypes.h> &
uint32_t instead... Unnecessary, though it's nice to know.






Comment 6


Callum McKenzie





          2004-08-28 07:12:57 UTC
        



Absolutely brilliant. This bug doesn't show up on little-endian 64-bit systems
and I hadn't had a chance to go through the code with a fine-toothed comb. I've
applied this in CVS.

In response to your second comment, it might be more pure, but we still can't
rely on having C99 available, gcc 2.9x is still widely used.







Comment 7


Callum McKenzie





          2004-10-04 23:13:15 UTC
        



*** Bug 154480 has been marked as a duplicate of this bug. ***






Comment 8


Callum McKenzie





          2005-04-21 07:37:58 UTC
        



*** Bug 170965 has been marked as a duplicate of this bug. ***