| | malloc() bug found -- BAD MEMORY REGION :-(
|
|
It looks like it's not a bug in legOS, but in the RCX hardware: Memory from 0xfb80 to 0xfd7f is simply NOT WRITEABLE, or more exactly, always read as 0xff, at least on my RCX ! Try the following little test: // // memory test // #include <conio.h> (...) (25 years ago, 1-Mar-00, to lugnet.robotics.rcx.legos)
|
|
| | malloc() bug haunt: getting closer..
|
|
Yesterday evening i found something, that might be the reason for some of the crashes reported lately: The chain of memory blocks used by malloc() has a broken entry, say: the reserved block at 0xfd7c has a length word of 0xfffe. This will cause (...) (25 years ago, 1-Mar-00, to lugnet.robotics.rcx.legos)
|
|
| | Re: Odd behavior
|
|
(...) afaik, with vanilla legOS-0.2.3, lnp_addressing_write and lnp_integrity_write are not thread-safe, there is a little patch fixing this in the lnpd tarball. (25 years ago, 29-Feb-00, to lugnet.robotics.rcx.legos)
|
|
| | Never mind
|
|
Well, my so-called "working" program crashed again, after adding two sleep statements and two sound calls, neither of which my program actually got to. So, I guess there are other causes behind my hangs as well. Ah the joys. :) -- "Though I am not (...) (25 years ago, 29-Feb-00, to lugnet.robotics.rcx.legos)
|
|
| | Re: Odd behavior
|
|
(...) For me, at least, it's not hanging during dll. My earlier problem was that dll just wouldn't complete with my program, but it didn't crash the RCX. By the way, I think I've found my crashing problem. It looks like I had some LCD calls that (...) (25 years ago, 29-Feb-00, to lugnet.robotics.rcx.legos)
|
|
| | Re: Directions to compile GCC
|
|
Luis Villa <liv@duke.edu> : (...) box (...) for (...) Wow Thanks! Here is the error I am getting-> loading cache ./config.cache checking if compiler cc1obj has been built... yes checking for gcc... h8300-hitachi-hms-gcc checking whether the C (...) (25 years ago, 28-Feb-00, to lugnet.robotics.rcx.legos)
|
|
| | Re: Directions to compile GCC
|
|
I've also been struggling with building the cross compiler. I'm trying to create a DJGPP hosted version. Once I am successful, we will be able to use Markus's legOS on DOS/Windows as-is. Currently, I have to rewrite Makefile.Common, Makefile.Kernel, (...) (25 years ago, 28-Feb-00, to lugnet.robotics.rcx.legos)
|
|
| | Re: Directions to compile GCC
|
|
(...) This may not be the case- the cross-compiler will try to compile something, but at least with the directions most of us use, there is no standard C library created and so the compiler thinks it doesn't work. The trick (then) is to use Markus's (...) (25 years ago, 28-Feb-00, to lugnet.robotics.rcx.legos)
|
|
| | Re: Directions to compile GCC
|
|
"Markus L. Noga" <markus@noga.de> : (...) Thanks! In one of the sections under this document there is a short paragraph explaining that cross compilers may not like having 32 bit ints (Like BeOS uses) turn into 16 bit ints (Like I bet the RCX uses) (...) (25 years ago, 28-Feb-00, to lugnet.robotics.rcx.legos)
|
|
| | Re: Directions to compile GCC
|
|
Jim Jackson <jjackson@jnjackson.com> : (...) GCC-2.95.2 (...) --host=i586-pc-beos (...) This gave me the Idea to tell the configure that I was running a Linux box (instead of a bebox) It almost worked too. At the end of the make the machine says I (...) (25 years ago, 28-Feb-00, to lugnet.robotics.rcx.legos)
|