News:

alphaMELTS 1.9 is available at the download and information site.
alphaMELTS 2 standalone & for MATLAB/Python are available on request
(see the Version 2 tab on the download site for more details).
For news of all MELTS software see the MELTS Facebook page.

Main Menu

Buffer Overrun with Write Input File option

Started by JohnKoziar, June 27, 2008, 07:34:49 AM

Previous topic - Next topic

JohnKoziar

When I write an input file after executing a string of calculations and then try to load the input file, partway through I get a "Buffer Overrun" error and the program crashes.

I believe the problem is that the written input file has too many digits! Each entry has six digits following the decimal. If there is a result in scientific notation, you can have as many as thirteen digits (1.234567e-008). It seems that exceeding seven digits overruns the buffer.

I have written a (not very robust) perl script to round all entries so that they have seven or fewer digits (turning the previous example into 1.23e-8), but I wonder if this is a flaw or if I am missing something?

Paula

I double checked the code and it shouldn't be writing out anything in scientific notation in the melts files i.e. 1.234567e-008 should simply be rounded down to zero.  So it's certainly a little odd and merits chasing up.  (That's not true for some of the other output files which can allow scientific notation for some variables.)  Likewise reading in scientific notation should not cause a problem unless the total line length gets long (> 130 characters, say), although a very small number (like < 1e-38) might get rounded down to zero.  I just tried it on Linux (32-bit) with all sorts of rubbish, including 'Initial Composition: SiO2 48.4621392345e-35', and it worked fine.

So without seeing any of the relevant files or knowing what platform you are on it's a little difficult to judge what's happening.  If you send me the files you are using for the first string of calculations and a bit more background information, I'll see if I can recreate the problem on a suitable machine and, hopefully, find the solution.  You can find my e-mail address in the 'Members List' when you are logged into the forum.  In the meantime, the workaround you have come up with sounds like a very good idea, although if you are getting extremely small numbers I would tend to round them to zero as the results won't be meaningful anyway.

More soon,
Paula

JohnKoziar

In case your spam filter ate my reply, here it is again:

First I am on Windows XP, Adiabat 2.0. Using the Workman_Hart_DMM.melts file with isentropic_melt.dat file, singly modifying "ADIABAT_DO_TRACE" to "true", I execute (4) at superliquidus (1). (I should mention that I am not interested in the results of this case.) I then write melts input file (14) choosing the residue composition (1).

When I try to read in this file, it reads each line successfully until it gets to  "Initial Trace: Ni 2620.479673", which is when I get the following message:

Buffer overrun detected!
Program C:\adi\adiabat_1ph.exe
A buffer overrun has been detected which has corrupted the program's internal state. The program cannot safely continue execution and must now be terminated.

Two inaccuracies from my initial post: it seems the number of digits in this case which sets off the error is ten or eleven, not eight (assuming that it is indeed the size of the entry that is causing the problem); and yes there are no results in scientific notation. The reason I was dealing with scientific notation is because I was actually using data from other output files to write my new input file.

Paula

The e-mail and files arrived fine, thanks, but it was a holiday weekend here and I didn't get to look at it properly till yesterday.  The problem is fixed (at least for the files you sent) in the current, not yet public, version.  I'm still trying to work out for sure why it was happening and why it was seemingly restricted to Windows...  Then I'll make an update available.

More soon,
Paula

Paula

O.K. all fine now.  It wasn't a Windows-specific problem after all - it just manifested itself differently on other platforms.  I had encountered it a while back on Linux when doing something else (testing upcoming new features) but it didn't seem to affect normal use.  And then I totally forgot about it!  So thanks for pointing it out.  I'll send you the updated Windows version now and then put updates for all platforms on the website by sometime tomorrow.

Cheers,
Paula