Re: Pico Bus error with OpenGL on Mac
Hi Alex, The *.s files don't assemble as expected: $ as -n x86-64.linux.base.s x86-64.linux.base.s:3:Unknown pseudo-op: .equiv x86-64.linux.base.s:3:Rest of line ignored. 1st junk character valued 72 (H). x86-64.linux.base.s:4:Unknown pseudo-op: .equiv x86-64.linux.base.s:4:Rest of line ignored. 1st junk character valued 67 (C). x86-64.linux.base.s:5:Unknown pseudo-op: .equiv x86-64.linux.base.s:5:Rest of line ignored. 1st junk character valued 90 (Z). x86-64.linux.base.s:6:Unknown pseudo-op: .equiv x86-64.linux.base.s:6:Rest of line ignored. 1st junk character valued 79 (O). x86-64.linux.base.s:7:Unknown pseudo-op: .equiv x86-64.linux.base.s:7:Rest of line ignored. 1st junk character valued 84 (T). x86-64.linux.base.s:8:Unknown pseudo-op: .equiv x86-64.linux.base.s:8:Rest of line ignored. 1st junk character valued 73 (I). x86-64.linux.base.s:9:Unknown pseudo-op: .equiv x86-64.linux.base.s:9:Rest of line ignored. 1st junk character valued 73 (I). x86-64.linux.base.s:10:Unknown pseudo-op: .equiv x86-64.linux.base.s:10:Rest of line ignored. 1st junk character valued 73 (I). x86-64.linux.base.s:11:Unknown pseudo-op: .equiv x86-64.linux.base.s:11:Rest of line ignored. 1st junk character valued 73 (I). ... -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Re: Pico Bus error with OpenGL on Mac
Hi Randall, $ as -n x86-64.linux.base.s x86-64.linux.base.s:3:Unknown pseudo-op: .equiv x86-64.linux.base.s:3:Rest of line ignored. 1st junk character valued 72 (H). Hm, is this in the Mac? The GNU assembler? It is extremely strange if it does not know the .equiv directive. Cheers, - Alex -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Re: Pico Bus error with OpenGL on Mac
Hi,
I have confirmed that this results in an immediate crash when I use Pico
Lisp 2.3.6 or newer on my Mac. However, I'm not sure what I can do
further to reveal what causes the memory to be overwritten. Any ideas?
/Jon
On 6/26/09 10:13 AM, Alexander Burger wrote:
Hi all,
now Randall and I made some experiments. I inserted the following code
on top of gltst.l
(load @simul/gl/lib.l)
(load @lib/gcc.l)
(gcc chk NIL 'heapCrc)
any heapCrc(any ex __attribute__((unused))) {
int c, i;
int crc = 0;
heap *h = Heaps;
char *p;
do {
p = (char*)h-cells;
do {
c = *p;
for (i = 0; i 8; ++i) {
if ((c ^ crc) 1)
crc ^= 0x14002; /* Polynom x**16 + x**15 + x**2 + 1 */
c = 1, crc = 1;
}
} while (++p (char*)(h-cells + CELLS));
} while (h = h-next);
printf(%d\n, crc);
return T;
}
/**/
# Pre-load functions to avoid later heap usage
(mapc getd
(quote
glut:Init glut:InitDisplayMode glut:InitWindowSize glut:CreateWindow
gl:ClearColor gl:MatrixMode gl:LoadIdentity gl:Ortho ) )
(setq Mode (| GLUT_SINGLE GLUT_RGB))
(prog # Pre-allocate heap
(heapCrc)
(glut:Init)
...
The intention was to repeatedly calculate the CRC sum over the Lisp
heaps (a linked list of malloc'ed memory blocks), to find out if and
when memory is overwritten by one of the graphics functions.
The code defines a 'heapCrc' function which prints the CRC sum, to be
compared to subsequent calls. The pre-loading of ot the 'glut:xxx and
'gl:xxx' functions, and the constant 'Mode' is necessary because
otherwise the heap would be changed by such side-effects.
Now, the interesting thing is: It crashes immediately! That is, it is
'heapCrc' itself that crashes (is this correct, Randall?). One of the
heap links must be broken, as the CRC calculation does not do anything
dangerous per se.
It is not clear for me if the memory is overwritten by the OpenGL
function, or already by the dlopen/dlsym mechanism when PicoLisp loads
the library. The latter case would mean that other dynamically loaded C
functions (including 'heapCrc') would also corrupt the system.
Perhaps somebody else likes to experiment with this (if time and a Mac
is available)?
Cheers,
- Alex
--
UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Re: Pico Bus error with OpenGL on Mac
Thomas: I think there was some other problem mentioned on this
mailing list that was caused by -O2...
Yes, don't compile pico lisp on a Ubuntu version newer than Feisty,
the result is highly unstable with O2, seems to be working with O1
though.
In any case I just don't compile pico lisp on newer versions, I've got
a virtual machine with Feisty which I use basically only to compile
pico lisp on.
/Henrik
On Sat, Jul 18, 2009 at 2:40 PM, Jon Kleiserjon.klei...@usit.uio.no wrote=
:
Hi,
I have confirmed that this results in an immediate crash when I use Pico
Lisp 2.3.6 or newer on my Mac. However, I'm not sure what I can do furthe=
r
to reveal what causes the memory to be overwritten. Any ideas?
/Jon
On 6/26/09 10:13 AM, Alexander Burger wrote:
Hi all,
now Randall and I made some experiments. I inserted the following code
on top of gltst.l
(load @simul/gl/lib.l)
(load @lib/gcc.l)
(gcc chk NIL 'heapCrc)
any heapCrc(any ex __attribute__((unused))) {
=A0 int c, i;
=A0 int crc =3D 0;
=A0 heap *h =3D Heaps;
=A0 char *p;
=A0 do {
=A0 =A0 =A0p =3D (char*)h-cells;
=A0 =A0 =A0do {
=A0 =A0 =A0 =A0 c =3D *p;
=A0 =A0 =A0 =A0 for (i =3D 0; i 8; ++i) {
=A0 =A0 =A0 =A0 =A0 =A0if ((c ^ crc) 1)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 crc ^=3D 0x14002; =A0/* Polynom x**16 + x**1=
5 + x**2 + 1 */
=A0 =A0 =A0 =A0 =A0 =A0c =3D 1, =A0crc =3D 1;
=A0 =A0 =A0 =A0 }
=A0 =A0 =A0} while (++p (char*)(h-cells + CELLS));
=A0 } while (h =3D h-next);
=A0 printf(%d\n, crc);
=A0 return T;
}
/**/
# Pre-load functions to avoid later heap usage
(mapc getd
=A0 (quote
=A0 =A0 =A0glut:Init glut:InitDisplayMode glut:InitWindowSize glut:Creat=
eWindow
=A0 =A0 =A0gl:ClearColor gl:MatrixMode gl:LoadIdentity gl:Ortho ) )
(setq Mode (| GLUT_SINGLE GLUT_RGB))
(prog =A0# Pre-allocate heap
=A0 (heapCrc)
=A0 (glut:Init)
=A0 ...
The intention was to repeatedly calculate the CRC sum over the Lisp
heaps (a linked list of malloc'ed memory blocks), to find out if and
when memory is overwritten by one of the graphics functions.
The code defines a 'heapCrc' function which prints the CRC sum, to be
compared to subsequent calls. The pre-loading of ot the 'glut:xxx and
'gl:xxx' functions, and the constant 'Mode' is necessary because
otherwise the heap would be changed by such side-effects.
Now, the interesting thing is: It crashes immediately! That is, it is
'heapCrc' itself that crashes (is this correct, Randall?). One of the
heap links must be broken, as the CRC calculation does not do anything
dangerous per se.
It is not clear for me if the memory is overwritten by the OpenGL
function, or already by the dlopen/dlsym mechanism when PicoLisp loads
the library. The latter case would mean that other dynamically loaded C
functions (including 'heapCrc') would also corrupt the system.
Perhaps somebody else likes to experiment with this (if time and a Mac
is available)?
Cheers,
- Alex
--
UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=3dunsubscribe
--
UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Re: Pico Bus error with OpenGL on Mac
This has nothing to do with this Mac problem, it's an old thing which breaks the functioning of pico lisp itself, while doing very basic stuff, as noted, it's been discussed at length before. /Henrik On Sat, Jul 18, 2009 at 4:52 PM, Alexander Burgera...@software-lab.de wrote: On Sat, Jul 18, 2009 at 03:08:34PM +0200, Henrik Sarvell wrote: Yes, don't compile pico lisp on a Ubuntu version newer than Feisty, the result is highly unstable with O2, seems to be working with O1 though. Hmm, I do not think that the problems here have to do with the C compiler. It rather seems that the loading of DLLs does not work (the inline C test code also results in a dynamically built dynamically loaded library). Cheers, - Alex -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Re: Pico Bus error with OpenGL on Mac
On Sat, Jul 18, 2009 at 05:06:50PM +0200, Henrik Sarvell wrote: This has nothing to do with this Mac problem, it's an old thing which True. One more reason to swicht to the 64-bit assembly version, which does not depend on any obscure compiler ;-) -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Re: Pico Bus error with OpenGL on Mac
Hi all,
now Randall and I made some experiments. I inserted the following code
on top of gltst.l
(load @simul/gl/lib.l)
(load @lib/gcc.l)
(gcc chk NIL 'heapCrc)
any heapCrc(any ex __attribute__((unused))) {
int c, i;
int crc = 0;
heap *h = Heaps;
char *p;
do {
p = (char*)h-cells;
do {
c = *p;
for (i = 0; i 8; ++i) {
if ((c ^ crc) 1)
crc ^= 0x14002; /* Polynom x**16 + x**15 + x**2 + 1 */
c = 1, crc = 1;
}
} while (++p (char*)(h-cells + CELLS));
} while (h = h-next);
printf(%d\n, crc);
return T;
}
/**/
# Pre-load functions to avoid later heap usage
(mapc getd
(quote
glut:Init glut:InitDisplayMode glut:InitWindowSize glut:CreateWindow
gl:ClearColor gl:MatrixMode gl:LoadIdentity gl:Ortho ) )
(setq Mode (| GLUT_SINGLE GLUT_RGB))
(prog # Pre-allocate heap
(heapCrc)
(glut:Init)
...
The intention was to repeatedly calculate the CRC sum over the Lisp
heaps (a linked list of malloc'ed memory blocks), to find out if and
when memory is overwritten by one of the graphics functions.
The code defines a 'heapCrc' function which prints the CRC sum, to be
compared to subsequent calls. The pre-loading of ot the 'glut:xxx and
'gl:xxx' functions, and the constant 'Mode' is necessary because
otherwise the heap would be changed by such side-effects.
Now, the interesting thing is: It crashes immediately! That is, it is
'heapCrc' itself that crashes (is this correct, Randall?). One of the
heap links must be broken, as the CRC calculation does not do anything
dangerous per se.
It is not clear for me if the memory is overwritten by the OpenGL
function, or already by the dlopen/dlsym mechanism when PicoLisp loads
the library. The latter case would mean that other dynamically loaded C
functions (including 'heapCrc') would also corrupt the system.
Perhaps somebody else likes to experiment with this (if time and a Mac
is available)?
Cheers,
- Alex
--
UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Re: Pico Bus error with OpenGL on Mac
Hi Tomas, Thanks for the suggestions. I may try some of those options, but not until I'm back from vacation some time in July. Me and my wife fly to Budapest on Monday. After Budapest we'll see what happens ... ;-) /Jon On 6/17/09 10:13 PM, Tomas Hlavaty wrote: Hi Jon, I tried this now, removed the -O2 flag from Makefile, and recompiled everything, but I still get the Bus error. :-( actually, how do you link your gl ffi functions to picolisp? If you use the dynamic loading feature, you should remove -O2 from @lib/gcc.l file too I think. You could also try to rebuild picolisp (and your gl ffi module) with -g option (debug) (both in Makefile and @lib/gcc.l). Then crash it and open both executable and core file in gdb to see what and where the problem was. I think gdb will probably complain that it could not find your gl ffi library (if it was loaded dynamically). Not sure how to avoid that easily but the error/crash message could give some clue anyway. It probably is something else, but it is worth trying. Or, as a workaround, you can try gtk-server http://www.gtk-server.org/ which started as gtk server but supports other libraries as well now (e.g. OpenGL). It became a ffi proxy server basically, very useful for scripting languages and for environments where you don't want to meddle with ffi (you can also mix 32bit and 64bit code -- they run in separate processes and also run gui programs on the server without any x windows installed). They have some examples on the website and you can also have a look at an experiment I did http://logand.com/gtk/gtk-gl-teapot.l a while ago. If you were thinking about going this route, I would publish the new improved version of picolisp gtk-server interface (better callback handling and glade support) sooner. That might not be what you want though if want to stay native os x and avoid gtk. Cheers, Tomas -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Re: Pico Bus error with OpenGL on Mac
Try other way: enable core dumps ulimit -c unlimited then run gltst, bus error will produce core file. Inspect it with gdb gdb program core If program's command line specified is wrong, gdb will tell you the right one read from core file. Randall Dow написав(ла): Hi Alex, Jon, I just installed the current testing picoLisp (now: 17.6.09) and the gl libraries. I get exactly your described behavior, Jon, gltst.l immediately produces a bus error signal. I then started it with gdb - and it runs fine - no buserror core dump. Hmmm. No more time right now. Cheers, - Rand On Tue, Jun 16, 2009 at 11:51 AM, Randall Dow randall@gmail.com wrote: I'll get everything installed, and let you know if I can reproduce the problem. -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Re: Pico Bus error with OpenGL on Mac
From the experiments with Jon before, I'm pretty sure that the crash occurs inside the garbage collector. This indicates that the heap is corrupted, probably when one of the 'gl:Xxxx' function is executed (as otherwise everything seems to run fine). The functions in gl.c and glut.c look fine, however. What if we insert a call to (gc) between each function call, to find out at which point the heap gets corrupted? (load @simul/gl/lib.l) (gc) (glut:Init) (gc) (glut:InitDisplayMode (| GLUT_SINGLE GLUT_RGB)) (gc) (glut:InitWindowSize 400 400) (gc) (glut:CreateWindow Test Window) (gc) (gl:ClearColor 0.7 0.2 0.2 0.0) (gc) (gl:MatrixMode GL_PROJECTION) (gc) ... We cannot be sure that (gc) crashes immediately, though. Better would be some heap checking function. Cheers, - Alex -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Re: Pico Bus error with OpenGL on Mac
Hi Jon, Randall and Alex, this might not be related but still an idea. Have you tried to build picolisp with gcc optimizations off? Recently, I had a problem with with code which was something like (mapcar char ...) where picolisp crashed for some strange reason. The problem went away when I removed -O2 flag from Makefile (I think it worked with -O1, not sure now). I think there was some other problem mentioned on this mailing list that was caused by -O2... Cheers, Tomas -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Re: Pico Bus error with OpenGL on Mac
Three things for me to try this evening... Rand On Wed, Jun 17, 2009 at 4:40 PM, Tomas Hlavaty t...@logand.com wrote: Hi Jon, Randall and Alex, this might not be related but still an idea. =C2=A0Have you tried to buil= d picolisp with gcc optimizations off? =C2=A0Recently, I had a problem with with code which was something like (mapcar char ...) where picolisp crashed for some strange reason. =C2=A0The problem went away when I remov= ed -O2 flag from Makefile (I think it worked with -O1, not sure now). =C2=A0= I think there was some other problem mentioned on this mailing list that was caused by -O2... Cheers, Tomas -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Re: Pico Bus error with OpenGL on Mac
Jon, Perhaps I can try it this week. I am interested in this. Alex, would you like to arrange a debugging session with me on a return trip through Munich? Rand On Tue, Jun 16, 2009 at 10:23 AM, Jon Kleiserjon.klei...@usit.uio.no wrote: I have now tested the OpenGL programs again, with the very latest testing version of Pico Lisp, and with the latest OS X (10.5.7) on my Mac, and I still get the Bus errors. If there are other users on this list that run Pico Lisp on Intel Mac, I would be interested to hear whether you get those Bus errors. The basic OpenGL library needed can be found here: http://folk.uio.no/jkleiser/pico/gl.tgz The most stripped down program that gives me Bus error, is this: http://folk.uio.no/jkleiser/pico/gltst.l As you see, it contains an explicit call to the garbage collector, (gc). All it takes to get the error here, is to move the mouse. Most of my other OpenGL programs give me a Bus error after a while. One exception is this: http://folk.uio.no/jkleiser/pico/gl/cube.l So, do you get the Bus errors on your Intel Mac? If you do, do you have any idea where the bug could be? (In the gl library, in Pico Lisp, or in the Mac OS X?) -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Re: Pico Bus error with OpenGL on Mac
Hi Randall, Alex, would you like to arrange a debugging session with me on a return trip through Munich? Good idea! I don't know yet whether I travel to Kufstein this week. I'll call you. Cheers, - Alex -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Re: Pico Bus error with OpenGL on Mac
Hi Alex, I'll get everything installed, and let you know if I can reproduce the problem. Cheers, - Rand On Tue, Jun 16, 2009 at 11:20 AM, Alexander Burgera...@software-lab.de wrote: Alex, would you like to arrange a debugging session with me on a return trip through Munich? Good idea! I don't know yet whether I travel to Kufstein this week. I'll call you. -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Re: Pico Bus error with OpenGL on Mac
Hi Alex, Jon, I just installed the current testing picoLisp (now: 17.6.09) and the gl libraries. I get exactly your described behavior, Jon, gltst.l immediately produces a bus error signal. I then started it with gdb - and it runs fine - no buserror core dump. Hmmm. No more time right now. Cheers, - Rand On Tue, Jun 16, 2009 at 11:51 AM, Randall Dow randall@gmail.com wrote: I'll get everything installed, and let you know if I can reproduce the problem. -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
