Buffer overrun on build 628

[Guest]

I have eSignal installed on two machines, and since I only have one account I can run on one machine at a time. On the newer machine, I have version 7.5 build 628 installed. One the older machine, I have version 7.5 build 627 installed. Both were running fine until today when I started getting this error when starting eSignal.

I had been running the same efs on both machines and I was having problems with both trying to share files over my home network. I had had to close both machines several times with Task manager when the machines locked trying to access shared files, at least several times with eSignal operating (on both machines.

Now I am getting the following error. I can get eSignal running if I delete the page files associated with the layout prior to starting it, however, once I save a page file layout and close eSignal, when I restart, I get the same error.

I reinstalled eSignal (not a complete uninstall / reinstall) to no avail. Does anyone have any insight ? My next step is a complete uninstall / reinstall.

TIA

[Gavishti]

I had the same problem today with 628. I was running debugPrint of three small numeric arrays. Largest was 13 elements. Restricting the print to displaying only four elements of one array let me proceed. I have 1GB of RAM, so memory shouldn't be a problem.

[Guest]

I had the same problem again tonight with the buffer overrun, I renamed the page file and I could boot up.

Now I had done this for a while after my last post, until that trick stopped working. I did a complete reinstall. That worked for a while, now I am having the problem again. I loaded the page file in my file share area. Any wisdom?

Regards,

[JayF]

Steve,

I tried downloading that Page File to test this out, but something's wrong. I suspect that either the link or the file is not setup right. Can you check it out?

[Guest]

Jay, Sorry, the link was bad, here it is again

page file

Thanks,


Steve

[JayF]

Hmm. The link looks ok now, however the Page File seems empty. When I open it I simply get an eSignal screen with no Windows open.

[dloomis]

Re: Reply to post 'Buffer overrun on build 628'

Same here Jay, nada

[Guest]

Maybe related to the error I am getting, I do not know. I am at a remote location today, so I will take a look at tonight and email a copy.

Thanks!

[gspiker]

I have seen the buffer overflow error also. It was directly related to a specific EFS which, due to a programming error on my part, was doing a lot more recursion than I though it was. What is odd is that it had run fine for many weeks, but one day the market created the right condition to trigger the error.

The only way to recover was to edit winsig.ini and change the default layout to be nothing, then recreate the page. In that way I narrowed the issue down to one chart (when the error happened again when I loaded that chart).

Repeat, but this time created the chart from scratch, which worked fine until I loaded the EFS in question.

Then debug the EFS.

It was a pain...but it was possible to work through it.

Hope this gives you some idea's on what the issue can be...sorry it is so choppy I have to dash and no time to make it pretty.

G

[RobMc]

I have just had the same error message and was having a panic because I couldn't get into eSignal and would be very uncomfortable with editing files etc. After reading this thread I thought that maybe it might be due to an efs (which I am experimenting with at the moment). I am not a technical expert but if my assumptions are correct and it is not coincidental then I seem to have resolved the problem quite simply in the following way.

1) Identify any efs routines that are currently loaded on the charts when you open eSignal.

2) Locate the efs in program files - esignal - formulas - etc (wherever you keep it)

3) Cut and paste the offending file(s) to My Documents

4) The big assumption is that presumably the files cannot then load because the filepath is changed??

On the next attempt, eSignal opened correctly with the efs names on the chart but I was able to remove them until I resolve any errors.

If anyone can tell me if that "should" work or if its coincidence I would be grateful. If it is correct then it is quite an easy workaround for someone who is not too technical.

Thanks
Rob

[ACM]

Rob
Another way to get back into eSignal is to go into the eSignal folder using Windows Explorer and double click any of the other Layouts available. This will open eSignal and load the selected Layout thereby bypassing the problems that may be caused by the the last running Layout.
An alternative is to edit the winsig.ini (after making a copy of it to be stored in a safe place) which is in the c:\windows (or c:\winnt) directory. In winsig.ini delete the path and file name in the line Layout= (at the very beginning of winsig.ini), then save the file and start eSignal.
Hope this helps
Alex

[z11]

Gentlemen,

I just got a Buffer Overrun Error just as the one shown in this thread which led to eSignal crash...I am running 7.9.1 and the EFS script had been working fine all along even a day ago on the same version. Any general idea as to where in an EFS (too many variables declared ?? too many studies declared?? ... etc?) might cause this error? Is this error akin to Access Violation in other languages?

Any general ideas as what might cause this error would be greatly appreciated.

ziggy

[Guest]

Hi ziggy,

I have had it before when I was declaring a large number of arrays as global variables using setGlobalValue () while allowing the variables in the arrays to go to full precision (e.g. 0.6338748089726594) What I did to remedy this was to limit the precision of the variables I was saving by using .toFixed(4) on the end of the variable.

Mine was a guess, based on your description. While you have include some of the details, I suggest that you post some more details as to when this occured. For example, what specific build of eSignal (e.g. version: eSignal 7.91 (Build 732)) you are using and either post the efs, or an example of the efs that demonstrates the phenomena, or if it wasn't associated with running the efs, more specifics that would allow someone to reproduce your problem.

[z11]

Steve, as always thanks for your reply.

I am running on build 732.
I do not (any more in EFS2) use any global variables.
By "limit the precision of the variables I was saving by using .toFixed(4) on the end of the variable.", what do you mean by "saving"? to a file or just assign local variables for later use or even passing these variables to a function outside of Main?

Thanks,

ziggy

[z11]

further detail of this error occurance:

it appeared that the EFS script had finished running and the error occured after the completion of the EFS....since I don't know where exactly in the EFS script that triggered this error, I can't even locate the general area in the script that would cause this error as the script itself had finished running (since this is weekend, last bar would not change on the chart.)

Further question on your suggestion of using .toFixed(4)... so should I use something like this?

var myStudy = macd(12,26,9);
var myMACD = myStudy.getValue(0).toFixed(4);

??

Thanks