Subj : Release of v3.4? To : Kees van Eeten From : Ulrich Schroeter Date : Sat May 25 2013 04:11:06 Hi Kees, Friday May 24 2013 23:44, you wrote to me: KE> Hello Ulrich! KE> 24 May 13 20:51, you wrote to me: KE> KE> If Bob is using the latest available precompiled version of makenl KE> for OS/2, it will probably be from the MN331O16.ZIP or the KE> MN331O32.ZIP as present on a.o. KE> http://sourceforge.net/projects/makenl/files/3.3.1/ KE> KE> could you try those two as well ? in the meantime I've got an OS32(32-bit) compile passed with OpenWatcom 1.9 With this OS/2 (32-bit) version of rev 3.3.3 code I can reproduce the crash reported =:) long detailed report you'll find under => https://sourceforge.net/p/makenl/bugs/17/ In summary .. its not about Allowunpub or other parameters ... The routine crashes after the segments are compiled and makenl tries to find the highest message number (~ SearchMaxMSG) The difference between the DOS revision (reg56-1.log) and the OS2 revision (reg56.log) you'll find in the report the reg56-1.log shows, that there are much more steps outstanding until makenl will finish with success ... success: ======== [...] d 24-May-2013 23:43:41 makenl[1850] Skip arc for r:\makenl\region56.144 d 24-May-2013 23:43:41 makenl[1850] OpenMSGFile entered d 24-May-2013 23:43:41 makenl[1850] OpenMSGFile: 2:292/854 filename=r:\makenl\region56.144 d 24-May-2013 23:43:41 makenl[1850] SearchMaxMSG(r:\makenl\NETMAIL) d 24-May-2013 23:43:41 makenl[1850] myfnmerge: drive='(null)' dir='(null)' name='*' ext='msg' d 24-May-2013 23:43:41 makenl[1850] SearchMaxMSG: path=r:\makenl\NETMAIL, result=5 d 24-May-2013 23:43:41 makenl[1850] OpenMSGFile: MSGnum is set to 5 [...] crashed: ======== [...] d 25-May-2013 03:19:38 makenl[259] Skip arc for l:\makenl\region56.151 d 25-May-2013 03:19:38 makenl[259] OpenMSGFile entered d 25-May-2013 03:19:38 makenl[259] OpenMSGFile: 2:292/854 filename=l:\makenl\region56.151 d 25-May-2013 03:19:38 makenl[259] SearchMaxMSG(l:\makenl\NETMAIL) d 25-May-2013 03:19:38 makenl[259] myfnmerge: drive='(null)' dir='(null)' name='*' ext='msg' [CRASHED] From my experiences in last year (rev 3.2.6 ff.) problems, I've still identified a stack pointer problem caused by the OpenWatcom 1.9 compiler and the used code with the OpenMsgFile routine (msgtool.c l.160) FixStack = NULL; /* BUGFIXED 2012-06-28 us filepointer/stack fix */ The story behind was: once calling the logwrite() routine (in mklog.c) the pointer gets garbaled open logfile works, but on return the still opened msgfile pointer has been changed (!!) and no longer points to the original filepointer, so therefor makenl terminated with "cannot open message file" because the filepointer was used for writing the log :-P Markus digged into this problem and found the Stackpointer problem My current "feeling" is, that this is another stack pointer problem in another area of the code while switching between routines KE> Kees regards, uli ;-) --- * Origin: AMBROSIA - Frankfurt/Main - Germany (2:244/1120) .