Custom Query (518 matches)

The window tries to open on some systems and closes immediately. No error message failure occurs in 3.06. If use fast internal viewer is unchecked viewing works fine.

The actual cause was the disk FM/2 was on was full. I lost filters.dat as a result. While a failure of some kind would be expected in this case it would be nice if it failed gracefully. Should I file a bug or is this just the way it is in a situation like this. The failure was in Module: D:\WATCOM/lib386/os2\clib3r.lib(mem) 0002:00043bf0 MemFree

according to the map file. Thanks

Gregg

08-24-2007 15:15:30 SYS3175 PID 04fa TID 0009 Slot 007d E:\FM2\FM3.EXE c0000005 1d323c7e P1=00000002 P2=00000008 P3=XXXXXXXX P4=XXXXXXXX EAX=00000000 EBX=00440000 ECX=0044495c EDX=00000000 ESI=00440000 EDI=00000000 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:1d323c7e CSACC=f0df CSLIM=ffffffff SS:ESP=0053:02dde58c SSACC=f0f3 SSLIM=ffffffff EBP=02dde60c FLG=00012206

FM3DLL.DLL 0002:00043c7e

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.