Memory allocation crash
- Posted by Roderick Jackson <rjackson at CSIWEB.COM> Jan 26, 1999
- 453 views
------ =_NextPart_000_01BE490D.21FA3200 Content-Transfer-Encoding: quoted-printable Hi all, I've been listening in on the Euphoria mailing list for a little while = now, having been using EU (2.0, the DOS version) to program for fun for = the past couple of months. I've got a problem that I think might be a = bug in the interpreter. I'm writing code to construct and manipulate my own, basic data = structures in memory (an intellectual exercise, hopefully bearing fruit = shortly...) I have set up a quick test program to test my = floating-point-number structure, which is basically based on Euphoria's = float64_to_atom() and atom_to_float64() functions right now. Apparently, = allocating space for these structures works fine. But I'm also managing = an internal, dynamic array of these structures. In the process of = iterating to (1) allocate space for new float structures and (2) move = each in memory onto the end of the array, the program crashes. It seems = as if the CauseWay DOS Extender built into Euphoria chokes for some = reason (I've attached the cw.err file for the specific errors). The strange part is, I'm displaying the array after each iteration, and = everything looks good up until after the 13th float is added (yes, the = 13th) Although the value of the floats is the same throughout the = program, suddenly two odd numbers pop up on-screen, and then the program = crashes. Furthermore, if I trace and step through the code starting at = iteration 13, step through an entire iteration, then let the program = continue, the two odd numbers still appear, but the program continues to = the end (and the rest of the values after the odd two are accurate.) I'm using the unregistered version on a Win95 system, 32MB of RAM, = Pentium II 233. I plan on registering eventually (particularly if this = works), but I don't see how the run-time debugging info would help this = problem. Does anyone have any ideas as to what is going on? Has this = kind of a problem been identified and addressed in version 2.1? I'm = hesitant to post the code itself since it's somewhat sizeable, but if = anyone (Rob, maybe?) wants to examine it for a closer look, I'm willing = to send it. ANY help or advice would be greatly appreciated! =20 Thanks, Rod Jackson ------ =_NextPart_000_01BE490D.21FA3200