Subj : Release of v3.3.6
To   : Andrew Leary
From : Ulrich Schroeter
Date : Wed Jun 05 2013 21:24:14

Hi Andrew,

Wednesday June 05 2013 09:40, you wrote to me:

 AL> Hello Ulrich!
 AL> Tuesday June 04 2013 03:15, Ulrich Schroeter wrote to Andrew Leary:
 US>> first, I've found the compile problem that is caused by
 US>> the filepointer around BatchFILE in main routine (makenl.c  line
 US>> ~325) see latest report under bug#17
 AL> ...
 US>> Whatever workaround I've tried to fix the return sequence
 US>> it crashes under OS/2 32-bit  :(
 AL> Yes, I know.

 US>> the problem may relate to the local int variable, that will be
 US>> used to return the result to the calling routine, where the
 US>> result will be assigned to a static int variable.
 AL> That is a definite possibility.  I'll have to research that further.

int variables tested around, that I can exclude to be the problem.
Yes, one shown bug with the  in maxnum = 0;  results in whatever value ...
but this isn't the cause for the crashing OS/2 32-bit executable   :-P

the last tests I've running without an integer return value
in the return sequence by setting
   void SearchMaxMSG()
and transfering the integer value via a static int variable SearchFeedback



 AL> It shouldn't be, but I'll look into that.  Maybe this is the result
 AL> of the work that was done to get the code to compile on 64-bit Linux
 AL> systems.

 US>> Someone with much more C/C++ experiences then me should dig into
 US>> this code section

 AL> I'm learning more all the time.

me too  =:)

ok, results found so far:

1. int variable problems doesn't interfer with the OS2 crash
   in SearchMaxMSG()

2. the OS/2 executable crashes in the SearchMaxMSG() routine while trying
   to jump to the return address within the calling function OpenMsgFILE()
       return <whatever>;
   this will do the executable guranteed (but I don't know why :( ......)

3. If the codebase (filesize of makenl.exe) increases, the crash address  
increases
   if the codebase decreases, the crash address decreases

4. The crash address is around 50.000 bytes below the variables areas

5. At least one known stack pointer problem we've found with the
   DOS/16 compile with OW19 while calling OpenMSGFile() (fixed 2012-06-28)

Research about OW19 bug reports about stack failures gives only diffuse results
that doesn't match exactly to our current problem.
No reports found that relates to function return exceptions



 AL> Andrew

regards, uli   ;-)

---
 * Origin: AMBROSIA - Frankfurt/Main - Germany (2:244/1120)

.