Apache OpenOffice (AOO) Bugzilla – Issue 10910
dmake throws exception
Last modified: 2003-06-27 09:20:18 UTC
The following describes a reproducable way to crash the MSVC 6.0 build dmake.exe Take your "normal" OOo build environement, with already generated winenv.bat. start a cygwin bash. In bash start a 4nt shell: $ c:/4NT401/4NT.EXE Go to your OOo source directory E:\>cd w1\testdmake Call winenv.bat E:\w1\testdmake>winenv.bat Enter soltools E:\w1\testdmake>cd soltools Build it! E:\w1\testdmake\soltools>build Boom! You get the following exception. You don't get this if you start 4nt from the desktop and not from a shell. You don't get this if you use a self-made MinGW dmake.exe
Created attachment 4421 [details] Picture of thrown exception
I build a debug version of dmake and found that in line 58 of dmake/tempnam.c: strcpy(dir, getenv(TempPath[n])); strcpy sometimes tries to copy the NULL pointer. This fails for MSVC. The following patch fixes this.
Created attachment 4422 [details] Patch for dmake/tempnam.c
applied in cws_ooo_so branch, to be integrated on mws644 soon.
Ooops. The patch is not wrong, but I had a discussion on IRC with Ken who pointed out that the real problem is the: #define tempnam dtempnam line in: dmake/win95/microsft/config.h tempnam is defined and working in MSVC 6.0, I was just at the moment adding a new patch for dmake to this IZ. It removes the usage tempnam.c for the MSVC build. My first patch is only a sanity check for strcpy, this one is the "real" fix. At the moment a OO643C build with a dmake without tempnam.c is running.
Created attachment 4424 [details] "Real" patch for dmake
verified.
The patch committed to cws_srx644_cws_ooo_so and mws_srx644 needs the following fix: --- tools/dmake/tempnam.c 2003/01/31 17:47:16 1.1.1.1.46.2 +++ tools/dmake/tempnam.c 2003/01/31 23:38:01 1.1.1.1.46.3 @@ -72,7 +72,7 @@ /* ret_val = new char[i+2 /* '\0' & '\\' *//* + 8 /*root*//* + 4 /*.ext*//*];*/ if (ret_val) { - strncpy(ret_val,dir, sizeof(retval)-1); + strncpy(ret_val,dir, sizeof(ret_val)-1); /* Make sure directory ends with a separator */ #if defined(DOS) || defined(PM2) || defined(WIN) || defined(WNT) @@ -109,7 +109,7 @@ #if defined(OS2) || defined(WIN) || defined(WNT) || defined(DOS) itoa(nTemp,ret_val + i,26); #else - snprintf(ret_val+i, sizeof(retval) + i, "%03u", nTemp); + snprintf(ret_val+i, sizeof(ret_val) + i, "%03u", nTemp); #endif strcat(ret_val,ext); nhandle = _open( ret_val, _O_CREAT | _O_EXCL, _S_IWRITE | _S_IREAD ); It looks as if tempnam.c is only used for the MSVC build, but it doesn't have to. Look at dmake_2.diff
Please apply and close this issue.
I checked in the following patch dmake_msc.diff. It consists of the part approved by Ken plus a few changes to make dmake builable with MSVC in the cws_srx644_ooo20030223 branch. I don't close the issue because I still think the dmake_2.diff is the correct way to fix this problem. As MSVC has the tempnam function we should use this library function and not the extra dtempnam version. Volker (I will remove the 11319 dependency because works the way it is)
Created attachment 4686 [details] Fix tempnam and make dmake buildable with MSVC
vq->mh: OK to apply the "Real" patch (dmake_2.diff) to cws_srx644_00020030309? I did a full build without tempnam.c, using the internal MSVC version and it build as usual. (In fact the CC=cl.exe ./configure && make) build version also doesn't use dempnam.c) I think this issue can be closed after that.
mh->vq: go ahead.
Committed dmake_2.diff to cws_srx644_ooo20030309. Closing issue ...
works
close