Subj : Debugged OS2-32bit bug (Release of v3.3.6) To : Andrew Leary From : Ulrich Schroeter Date : Sat Jul 13 2013 23:59:18 Hi Andrew, Tuesday June 25 2013 12:09, you wrote to me: AL> Hello Ulrich! AL> 24 Jun 13 00:39, you wrote to me: AL>>> This appears to be an OpenWatcom issue. I've already modified AL>>> the code to use version b, with no effect on the SearchMaxMSG AL>>> crash under OS/2. AL> ... US>> based on the oswatfnd.c, oswatful.c, oswatxxx.h, osgenaps.c and US>> os.c an ASM routine _dos_findnext() starts moving around some US>> memory in the debugger it identifies itself as: Assembly: findos2 US>> 005B:0002AF6A findos2@copydir_+0000002A AL> .. AL> Yes, that is definitely a problem. AL> US>> Solution(s) ? US>> I don't realy know ... US>> I assume, that the findfirst() / findnext() code requires a US>> defined memory allocation ?!? -or- further investigation is US>> needed to discover the reason, why _dos_findnext() writes into a US>> memory area that is allocated by the active process AL> AL> It appears to be a problem with OpenWatcom 1.9. I will attempt to AL> compile the code with an older version to see if this resolves the AL> issue for MakeNL. ok, I've worked on a workaround for the _dos_findfirst() / _dos_findnext() routines together with Markus the last 2? 3? weeks. Today I've got an alternate bundle of DosFindFirst() / DosFindNext() routines compiled. The program started running ... and crashed too :( Of special interest is, that the program crashed unrelated to the SearchMaxMSG routine. In the preparation steps, makenl collects the files defined in the makenl control file, while scanning update, inbound and working directory through the myfnmerge() routine. With the new routines included (findfirs.c, findnext.c from watcom ow19 src Bld/Clib/File/C) the program probably crashes, while trying to transfer the results found in the low-level clib routines to the makenl data working area. As seen in my debug run of the original makenl code, the _dos_findnext() information transfer started overwriting areas of the codes local data area. It looks like, that there is not enough memory available, so the segments started overlapping that results in the crash that brings me back to below still known report (I still did not a debug run, but probably the result is similar to the previously published debug result ... that the low level routine starts overwriting local data area of the running code) US>> As least similar findfirst() findnext() routines US>> as shown under US>> http://www.openwatcom.org:4000/@md=d&cd=//&cdf=//depot/public/4os US>> 2/c/w rappers.c US>> &ra=s&c=rGG@//depot/public/4os2/c/wrappers.c?ac=64 has some more US>> code included. AL> US>> here 2 comments are of interest: US>> 20 Aug 07 GKY Move #pragma alloc_text to end for OpenWatcom US>> compat 01 Sep 07 GKY Add xDosSetPathInfo to fix case where FS3 US>> buffer crosses 64k boundry ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ US>> maybe something similar is required for the makenl_ng code ?!? AL> Possibly; if so it will take some time to research and implement. AL> Thanks for the help in debugging this; it is greatly appreciated. my C experiences are far from such experiences required, to get such a task running ... I still have no idea how such extended memory usage monitoring can be implemented, to prevent overlapping of data areas From other non-C compile and link projects, I know that its possible to receive a map of memory layout for the compiled program, that may help in analysing the memory requirements by the compiled program. But I'm currently don't know how I can add this to the watcom compile and link configuration I still start the compile with the following commandline wmake -f makefos2.wat DEBUG=1 OS=OS2 >> comp_os2.log where makefos2.wat is the copied watcom.compile file from the makenl_ng distribution package within the watcom.compile file I don't know which flags I can set so that a map layout file will be written in the compile run AL> Andrew regards, uli ;-) --- * Origin: AMBROSIA - Frankfurt/Main - Germany (2:244/1120) .