Erratic Behavior

[LarryMc]

Working on a project that has 26 source files.
The project has one main window and 20 others that are shown/hidden at the proper times.
One module and window acts as my menu with my custom buttons.
The menu has been working correctly in this project for the last 1-1/2 months while I'm fleshing out the program.

About a 1/2 dozen of my windows have hidden list view controls to hide data "records" while the screens are being operated on.

After adding the most recent module I noticed that my menu window buttons quit displaying properly.  One changed shape and if I moused over it the buttons after it would not changed like they were suppose to when I moved the mouse of them.  Also the buttons would restore different windows than they were suppose to when clicked.

After bypassing code in the last module I added I found that inserting the initial record into its LV was causing the problem.
With the insertion there the menu ( in another source file) was messed up but when I rem'd the insertion the menu was fine.

I then rem'd an insertion of a different LV in a different window in a different source file and put in the insertion in the last module and my menu worked correctly.  Went through that with other modules.

The appearance is that I've hit a limit somewhere.  I have no problem adding the LV and inserting columns.  It's just when I try to insert a new row, regardless of what module I try to insert it in.

Has anyone run into anything similar?

Larry

[Ionic Wind Support Team]

Larry,
Hard to tell by the description.  Are you using an actual project, with separate source files added to the project?

There are physical limits to the COFF object file format that I've run into before.  For example if you are $including other source files, instead of adding them to the project like you are supposed to do, then you are creating one big object file instead of separate ones.  The limit I am speaking of has to do with the size of the data segment of a COFF object  (.o extension) and you can run into it if you have too many literal strings being compiled.

Paul.

[LarryMc]

Are you using an actual project, with separate source files added to the project?

Yes

... if you have too many literal strings being compiled.

I've got a bunch but I've had more in other projects I believe.

My biggest o-files are 17/18K

Attached is my map file if it will tell you anything.

Larry

[LarryMc]

  The limit I am speaking of has to do with the size of the data segment of a COFF object  (.o extension) and you can run into it if you have too many literal strings being compiled.

How can I tell if that is it?
And if I have that problem and need those strings then how do I work around it?

Larry

[Ionic Wind Support Team]

Larry,
Don't bark up the wrong tree.  The only time I have seen it was a user that was $including 20-30 other source files in his main source file, if as you say the largest .o file is only 16 - 17K then it is probably not the problem.

Paul.

[LarryMc]

Got any idea at all how I can go about trying to figure out what's causing the problem?
Like the types of changes I might try?

I know you're limited by not having all the source code but I don't want to ask you to get bogged down in that until I have done everything that I can possibly do.

I have my chart.lib linked into this program and it's o-file is 98k.
Does that have any bearing on anything?

Larry

[Ionic Wind Support Team]

Larry,
Just too vague for me to hazard another guess.  Could be anything from memory corruption, which isn't being run into until you reach a certain point, to stack overflows.  Any issues when you compile a debug mode executable and run it?

Paul.

[LarryMc]

Appears to be a string problem.
I shortened the names of the 6 columns in 1 LV from a total of about 30 characters to 13 characters and it started working correctly.

Would putting all my quoted strings in the res file help out with that issue?

Larry

[Ionic Wind Support Team]

Larry,
Having never encountered the problem I can't give you a definitive answer.  In the large project I worked on for that contract we had dozens of listviews all operating at once, with a lot of data in them, long column names, and didn't have any issues.

While shortening a string or 6 might have delayed the problem, you will most likely run into it again later on, until you get to the real cause of it.  It is a very good possibility that strings have nothing to do with the problem.  I have to reiterate you are not experiencing the same problem I did with a COFF file limit.

Go through your program and look for the obvious things.  Not deleting memory, overwriting array boundaries, overwriting string boundaries, etc.   The other programmer I worked with on that contract job would consistently forget about the NULL terminator on strings and do things like this:

istring name[16]
name = left$(inp, 16)

Which of course overwrites one byte of memory if the input string is longer than 15 characters.  Those kind of overwrites are very hard to track down, and can lead to seemingly bizarre behavior in completely unrelated sections of code.  Running it as a debug executable can help track down those by generating heap exceptions, but not always.

Try also increasing the stack size of the build. 

Paul.

[LarryMc]

I doubled the stack size with no change.

BTW, the help manual says I can add string resources using @resstring to load them.
I had absolutely no luck in getting that to work.

Larry

[LarryMc]

with a debug build the problem goes away.


Larry

[LarryMc]

It gets worse.
Prior to the debug build I had absolute control over when it would fail just by adding/removing 1 character from a string.
After the debug build I recompiled without debug and the problem is magically gone no matter how many characters I add.

[Ionic Wind Support Team]

We'll then you've solved it

Could have been a locked file on the drive, run into that on occasion.  Start fresh, delete all .o and .a files, any $$$lib.link files, and rebuild all.

Are you sure the program is exiting correctly?  Check task manager to see if any old images are still running.

Here is my reply before your last post:
-------------------------------------------------------------------------------------------------------------------------------------------
Larry,
It's common for memory overwrites not to occur at the same location in memory with a debug mode build, because the memory segments end up at a different location.  That alone tells me you are overwriting memory.  Whether it be an array, a string, or whatever is up to you to find. 

BTW, the help manual says I can add string resources using @resstring to load them.

Actually the users guide says it is one of the standard Windows resource types.   Emergence doesn't have the facilities to add strings to resource files currently.  Although if you manually edit the .rc file you can add string resources, they are stored in unicode.  So you can use LOADRESOURCE to get a pointer to a string resource and #<WSTRING>pWhatever to read it.

In any event you seem to be missing the point.

The problem probably has nothing to do with strings.

That's all the clairvoyant help I can give right now.  Considering you are basically asking for our help debugging code that we've never seen.  You are going to have to go through your code, line by line, to find the problem.  I know it can be a pain, but I have had to do it more times than I can remember.  Usually printing out the code and going through it with a highlighter helps.  Check every array index, every string assignments dealing with dimensioned strings, every pointer operation where a memory overwrite could happen.  The most common memory corruption happens with arrays, zero based indexes can trip you up if you aren't looking, and aren't used to them.

Paul.