[cells-devel] Small progress: GLUT-INIT not called due to false init value checking
Hi Kenn & all: I just discovered that GLUT wasn't initialized properly in cl-glut-init. This is due to the (zerop glut-state) which I turned into (or (eq glut-state 0) (eq glut-state -1)) Also, I found that when calling glut-init I run into a "a MACPTR cannot be coerced to INTEGER" error. So I fiddled with the call to glut-init (all in file glut-extras.lisp) and replaced the argc argument with a fixed integer value, 1. Now I see a new Dock element, a terminal that shows the OpenMCL text when going over it with the mouse. Unfortunately, OpenMCL now does not return from that call. So I suppose we have a FFI problem here, most probably some problems with pointers. Now, this is a new one for me, so it will take some time to fix it. Suggestions? Thx! Happy Hacking - Frank
I just realized a couple of things.... Frank Goenninger wrote:
Hi Kenn & all:
I just discovered that GLUT wasn't initialized properly in cl-glut-init.
This is due to the (zerop glut-state) which I turned into
(or (eq glut-state 0) (eq glut-state -1))
I am guessing you did this because you saw -1 coming back from (glutGet glut_init_state). That would mean glut is already initialized, and it might be an error (leading to a silent shut-down via exit()) to call glutInit when glut is already initialized (I do seem to recall that in Freeglut). This is where it gets tricky being a Lisp developer. :) Anyway, I /think/ the zerop was the correct test. If you are seeing a -1 come back when you are sure glut is not initialized, then we might have an FFI problem (I doubt -1 is being used to signify false).
Also, I found that when calling glut-init I run into a
"a MACPTR cannot be coerced to INTEGER"
error. So I fiddled with the call to glut-init (all in file glut-extras.lisp) and replaced the argc argument with a fixed integer value, 1.
Whoa, I missed that. Two things: (1) glutInit wants a pointer to an integer. That is why we allocate an array, stuff the integer into index zero and pass the array -- that is effectively passing a pointer to the first element of the array. (2) We are not passing any argv's to glutInit, so you have to pass (a pointer to) zero as the argc. C functions have no way of knowing how many argvs are being passed, so that is why there is also the argc argument. I do not know how C survived being passed an integer address of 1, but if it does not see zero it takes the value of argv as a pointer to the first pointer to an argv. We are passing null for argv, so C would blindly be examining address 0 and thinking it was a pointer. Possibly what has happened is that glutInit saw enough to decide it should start up a proper app with window, so things happened in the dock, but when it finally got around to looking at the args, it died on a bad pointer. On win32 I was able to place breakpoints (by coding "assert( false );") in glut code in VC6 and rebuilding the DLL. (I had to call unload-foreign-library on the dll before rebuilding or VC6 would be unable to overwrite the old one). Then when I ran I could (at first) actually get into the VC6 debugger. Unfortunately, the last time I tried this I could not debug, so it was one test and then shutdown the whole Lisp IDE. To improve on this, I had Freeglut put up a win32 alert box instead of using assert( false), so I could get the DLL to report back some info before continuing execution. In this case I would add alerts to glutInit and glutCheckLoop and glutCreateWindow so I could see what was going on. Well, that is if Apple makes a Glut ProjectBuilder. I will install XCode on my new toy now and see what I can see. cheers, kt
Hi again.. On Mon, 2004-10-25 at 10:46, Kenny Tilton wrote:
I just realized a couple of things....
Frank Goenninger wrote:
Hi Kenn & all:
I just discovered that GLUT wasn't initialized properly in cl-glut-init.
This is due to the (zerop glut-state) which I turned into
(or (eq glut-state 0) (eq glut-state -1))
I am guessing you did this because you saw -1 coming back from (glutGet glut_init_state). That would mean glut is already initialized, and it might be an error (leading to a silent shut-down via exit()) to call glutInit when glut is already initialized (I do seem to recall that in Freeglut).
You're right here. My assumption (and assumptions are never an easy thing) was that -1 meant "Not initialized yet" and I didn't check the GLUT specs for that.
This is where it gets tricky being a Lisp developer. :)
Well, still counting myself as a newbie I am looking for ways of learning the art of being more advanced ...
Anyway, I /think/ the zerop was the correct test. If you are seeing a -1 come back when you are sure glut is not initialized, then we might have an FFI problem (I doubt -1 is being used to signify false).
I will check the GLUT specs for that now.
Also, I found that when calling glut-init I run into a
"a MACPTR cannot be coerced to INTEGER"
error. So I fiddled with the call to glut-init (all in file glut-extras.lisp) and replaced the argc argument with a fixed integer value, 1.
Whoa, I missed that. Two things:
(1) glutInit wants a pointer to an integer. That is why we allocate an array, stuff the integer into index zero and pass the array -- that is effectively passing a pointer to the first element of the array.
(2) We are not passing any argv's to glutInit, so you have to pass (a pointer to) zero as the argc. C functions have no way of knowing how many argvs are being passed, so that is why there is also the argc argument. I do not know how C survived being passed an integer address of 1, but if it does not see zero it takes the value of argv as a pointer to the first pointer to an argv. We are passing null for argv, so C would blindly be examining address 0 and thinking it was a pointer.
Fully understood so far with more than 5 years of professional C programming under my belt ;-))
Possibly what has happened is that glutInit saw enough to decide it should start up a proper app with window, so things happened in the dock, but when it finally got around to looking at the args, it died on a bad pointer.
Yep. I suppose that's what is happening here.
On win32 I was able to place breakpoints (by coding "assert( false );") in glut code in VC6 and rebuilding the DLL. (I had to call unload-foreign-library on the dll before rebuilding or VC6 would be unable to overwrite the old one). Then when I ran I could (at first) actually get into the VC6 debugger. Unfortunately, the last time I tried this I could not debug, so it was one test and then shutdown the whole Lisp IDE. To improve on this, I had Freeglut put up a win32 alert box instead of using assert( false), so I could get the DLL to report back some info before continuing execution.
In this case I would add alerts to glutInit and glutCheckLoop and glutCreateWindow so I could see what was going on. Well, that is if Apple makes a Glut ProjectBuilder. I will install XCode on my new toy now and see what I can see.
Not seen any of kind of source for Apple's GLUT yet. So this will be key if we want to go the route you suggested for debugging.
cheers, kt
Now I have a busy Monday just starting with writing a proposal for a (hopefully) client to get some money flowing in ... Frank
participants (2)
-
Frank Goenninger -
Kenny Tilton