Memory allocation crash

new topic     » topic index » view thread      » older message » newer message

------ =_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

new topic     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu