Custom Query (518 matches)

Testcase

Go to the XWorkplace\bin directory.

Select the "xwpdaemn.exe"

Go up to the toolbar and select the "Object info" bmp.

The "file/directory object information" comes up.

Click the "Cancel" button.

Now do the same thing over again. The second time, FM/2 crashes and leaves entries in the os2popup.log.

08-22-2007 22:11:14 SYS3175 PID 003c TID 0008 Slot 008e F:\TOOLS\FM2\FM3.EXE c0000005 00444d9c P1=00000002 P2=00000000 P3=XXXXXXXX P4=XXXXXXXX EAX=00000000 EBX=00000000 ECX=0008003c EDX=13e8af20 ESI=004427b8 EDI=8000018d DS=0053 DSACC=f0f3 DSLIM=ffffffff ES=0053 ESACC=f0f3 ESLIM=ffffffff FS=150b FSACC=00f3 FSLIM=00000030 GS=0000 GSACC= GSLIM= CS:EIP=005b:00444d9c CSACC=f0df CSLIM=ffffffff SS:ESP=0053:02c9d624 SSACC=f0f3 SSLIM=ffffffff EBP=02c9d75c FLG=00012212

FM3DLL.DLL

Gregg stated that he can reproduce it and already has a trap dump.

FM3.ini was being marked readonly. Opening up multiple instances caused a readonly error message to pop up.

The file causing this was the init.c file located in the dll subdirectory of the trunk. Changes were made, nothing that should have caused this problem.

It appears that we have stumbled upon a 32-bit code defect in the kernel which I can now reproduce on demand. Here's the testcase output

DosQueryPathInfo? J:\SLA_DEV2\FM2.DEV\test\fm3.ini returned 0 DosSetPathInfo? 00160000 J:\SLA_DEV2\FM2.DEV\test\fm3.ini returned 0 DosQueryPathInfo? J:\SLA_DEV2\FM2.DEV\test\fm3.ini returned 0 DosSetPathInfo? 0015fffc J:\SLA_DEV2\FM2.DEV\test\fm3.ini returned 123

The hex value is the address of the FILESTATUS3 buffer.

I've suspected that was the problem all along, but overlooked the location of the FILESTATUS3 buffer and kept looking at the filename buffer. Oh well.

DosSetPathInfo? is a 32-bit wrapper for the original 16-bit code. The way this supposed to work is that the 32-bit wrapper is supposed to ensure any 16-bit alignment rules are followed.

Bad luck had is that in the 3.0.7 build, the FILESTATUS3 buffer crossed a 64K boundary and the 32-bit wrapper code does not handle this properly.

Anyway, I will be committing an update to init.c that works around this.

Fortunately, DosSetPathInfo? is not used a lot, so there's not a lot to fix.

Now that I know where the failure is located, I knew what to look for to make sure I had not just rediscovered and know issue. There was some discussion on comp.os.os2.programmer about a defect in DosSetPathInfo? that was fixed by the 14.104 kernel, but it not our specific problem. Is anyone with the INI rewrite error running this kernel or 14.104a? It would be nice to know if the updated kernel fixes our problem too.

FM3.ini was being marked readonly. Opening up multiple instances caused a readonly error message to pop up.

The file causing this was the init.c file located in the dll subdirectory of the trunk. Changes were made, nothing that should have caused this problem.

It appears that we have stumbled upon a 32-bit code defect in the kernel which I can now reproduce on demand. Here's the testcase output

DosQueryPathInfo? J:\SLA_DEV2\FM2.DEV\test\fm3.ini returned 0 DosSetPathInfo? 00160000 J:\SLA_DEV2\FM2.DEV\test\fm3.ini returned 0 DosQueryPathInfo? J:\SLA_DEV2\FM2.DEV\test\fm3.ini returned 0 DosSetPathInfo? 0015fffc J:\SLA_DEV2\FM2.DEV\test\fm3.ini returned 123

The hex value is the address of the FILESTATUS3 buffer.

I've suspected that was the problem all along, but overlooked the location of the FILESTATUS3 buffer and kept looking at the filename buffer. Oh well.

DosSetPathInfo? is a 32-bit wrapper for the original 16-bit code. The way this supposed to work is that the 32-bit wrapper is supposed to ensure any 16-bit alignment rules are followed.

Bad luck had is that in the 3.0.7 build, the FILESTATUS3 buffer crossed a 64K boundary and the 32-bit wrapper code does not handle this properly.

Anyway, I will be committing an update to init.c that works around this.

Fortunately, DosSetPathInfo? is not used a lot, so there's not a lot to fix.

Now that I know where the failure is located, I knew what to look for to make sure I had not just rediscovered and know issue. There was some discussion on comp.os.os2.programmer about a defect in DosSetPathInfo? that was fixed by the 14.104 kernel, but it not our specific problem. Is anyone with the INI rewrite error running this kernel or 14.104a? It would be nice to know if the updated kernel fixes our problem too.