wiki:DevelopersFAQ

DevelopersFAQ

Here you can find answers to some of the most frequently asked questions about development of FM/2. If you have

a question not answered on this page, you can ask it at

http://tech.groups.yahoo.com/group/fm2user/


  1. Trouble Shooting
    1. How to find the source code for a trap?
    2. When the trap is in the watcom libraries, how can I trace it back to the actual call in the source?
    3. Can a hardware breakpoint be used to detect a spurious write?
    4. If all the traps are in the library code, what does this possibly mean?
  2. Error Messages
    1. The source fails to build displaying the following error message
    2. This error message says you have a bad bitmap
    3. Error message indicating wrong rc.exe
  3. Coding Questions
    1. Is the code below OK? Did I account for the terminating nulls correctly?
    2. What is the purpose of quoting functions?
    3. Where is the best place to do a check for?


Trouble Shooting

How to find the source code for a trap?

The OpenWatcom maps do not provide the source line detail that the VAC maps provided, so the procedure for locating the trapping source code line changes a bit, but it's still reasonable easy.

Grab the object:offset value for the failing cs:eip from popuplog.os2.

Sort the memory map section of fm3dll.map.

FInd the function containing the trapping object:offset value.

Calculate the offset from the function start to the object:offset value.

Determine the source file for the function containing the trapping function.

Run

wdis -l -s filename.obj

where filename is the source file base name. This will create filename.lst.

Find the failing function in filename.lst

Find the calculated offset.

This is the line that trapped.

There will be labels of the form L$289. These are relative to the function start so it's easy to find the matching source code in filename.c

When the trap is in the watcom libraries, how can I trace it back to the actual call in the source?

For this you need a trap dump file. Then you can let pmdf do the work. You need my mapsymw.pl to convert the Watcom map file to something pmdf can use. To get my mapsymw.pl, you can contact me at

Steven H. Levine
steve53@…

You can also use the Watcom debugger. It can give you a call trace too.

Can a hardware breakpoint be used to detect a spurious write?

You can if the exception address shown in the popuplog P2 field is consistent.

If all the traps are in the library code, what does this possibly mean?

This is not unusual for buffer overflows. Each buffer in the heap has a header and depending on the implementation a trailer which contains counts and/or pointers. If you wipe out one of these, a trap will follow soon enough.



Error Messages

The source fails to build displaying the following error message

wcc386 -bt=os2 -mf -bd -bm -d1 -olirs -s -sg -j -wx -zfp -zgp -zq -hd arccnrs.c
F:\OS2TK45\h\libc\stdarg.h(83): Warning! W138: No newline at end of file
F:\OS2TK45\h\libc\stdlib.h(544): Warning! W138: No newline at end of file
F:\OS2TK45\h\libc\string.h(378): Warning! W138: No newline at end of file
F:\OS2TK45\h\libc\time.h(136): Warning! W138: No newline at end of file
F:\OS2TK45\h\libc\direct.h(92): Warning! W138: No newline at end of file
F:\OS2TK45\h\libc\share.h(49): Warning! W138: No newline at end of file
F:\OS2TK45\h\libc\process.h(215): Warning! W138: No newline at end of file
arccnrs.c(183): Error! E1071: Type of parameter 3 does not agree with
previous definition
arccnrs.c(183): Note! N2003: source conversion type is 'void
*(*)(unsigned long p1,unsigned long p2,void *p3,void *p4)'
arccnrs.c(183): Note! N2004: target conversion type is 'void
*(_Syscall *)(unsigned long p1,unsigned long p2,void *p3,void
*
p4)'
arccnrs.c(610): Error! E1011: Symbol 'SH_DENYWR' has not been declared
arccnrs.c(610): Warning! W102: Type mismatch (warning)

etc...

Since FM/2 now uses the OpenWatcom Warp Toolkit, you have to modify your config.sys statement moving the OpenWatcom? entries ahead of the IBM Toolkit entries, save, and reboot.

This error message says you have a bad bitmap

RC :(fm3.RC:71:8):Error 2034:RC cannot create resource item type '2'
and id '999'. RC :(fm3.RC:71:8):Error 2037:RC failed to add a resource. The
return code is '7'.

This says you have a bad bitmap. What you need to do is figure out the file name. Start with fm3dll2.h. Find the name assigned to id 999. This is IDM_HELP. Look this up in fm3.rc. This says there's something wrong with your copy of bitmaps\HELP.BMP.

Error message indicating wrong rc.exe

Operating System/2 Program Maintenance Utility
Version 4.00.001 Oct 4 2001
Copyright (C) IBM Corporation 1988-2001
Copyright (C) Microsoft Corp. 1988-1991
All rights reserved.

Updating resources only
nmake /nologo / MAKERES=1
cd dll
nmake /nologo /L
internal\mkstr
SYS1041: The name internal\mkstr is not recognized as an
internal or external command, operable program or batch file.
NMAKE : fatal error U1077: 'D:\OS2\CMD.EXE' : return code '1041'
Stop.

Try running rc.exe from the command line. You will probably see

Operating System/2 Resource Compiler
Version 4.00.006 Sep 16 1997

What you need to see is

IBM RC (Resource Compiler) Version 5.00.002 Dec 18 1997

Move the defective rc.exe out of the PATH and your problems are likely to disappear.

The problem files are

[d:\toolkit\archived]dir rc*

Volume in drive D is DRV_D Serial number is A8CB:6815[[BR]] Directory of D:\Toolkit\Archived\rc*

4-27-98 12:14 88,051 0 RC.EXE
4-27-98 12:14 111,908 0 RC4.INF
4-27-98 12:14 15,314 0 RCPP.ERR
4-27-98 12:14 47,331 0 RCPP.EXE
262,604 bytes in 4 files and 0 dirs 263,168 bytes allocated
2,788,724,736 bytes free

As you might notice, I store these files in the Archived directory just in case I need to maintain something to insists on using this version of rc.


Coding Questions

Is the code below OK? Did I account for the terminating nulls correctly?

//BldFullPathName returns the fullpath of a file or Nullstr
CHAR *FullPathName = BldFullPathName(CHAR *pathname, CHAR
*filename)
{

CHAR newname[CCHMAXPATH] = Nullstr;
INT c = 0;

c = strlen(pathname);
if (c > 0) {
memcpy(newname, pathname, c + 1);
if (newname[c] != '\\')
newname[c++] = '\\';
}
strcpy(newname + c, filename);
return newname;
}

//BldQuotedFullPathName returns the quoted fullpath of a file or ""
CHAR *FullPathName = BldQuotedFullPathName(CHAR *pathname,
CHAR *filename)
{

CHAR newname[CCHMAXPATH] = '\"';
INT c = 0;

c = strlen(pathname);
if (c > 0) {
memcpy(newname + 1, pathname, c + 2);
if (newname[c + 1] != '\\')
newname[c + 2] = '\\';
strcpy(newname + c + 3, filename);
}
else
strcpy(newname + 1, filename)
strcat(newname, '\"')
return newname;
}

Not quite. The caller must pass a pointer to the buffer. Keep in mind that local variable disappear when the function returns.

PSZ BldFullPathName(PSZ fullPathName, PSZ dirname, PSZ filename);
CHAR newname[CCHMAXPATH] = Nullstr;

This will give you an error because NullStr? is a pointer.

CHAR newname[CCHMAXPATH];

Is sufficent since you are always going to copy something. The return is

return fullPathName

with the appropriate name changes.

//BldQuotedFullPathName returns the quoted fullpath of a file or "" CHAR

The quotes need to be optional and the return buffer needs to be passed as above.

PSZ BldQuotedFullPathName(PSZ fullPathName, PSZ pathname, PSZ filename)

You also need to add the calls to needs_quotes() a stuff the quotes only if needed. This is what the existing inline code does.

What is the purpose of quoting functions?

Its purpose is to replace repeated occurances of code of the form

sprintf(cl, "%s %s%s%s", dcd->info->delete,
(needs_quoting(dcd->arcname)) ? "\"" : NullStr,
dcd->arcname,
(needs_quoting(dcd->arcname)) ? "\"" : NullStr);

and possibly

runemf2(SEPARATEKEEP | WINDOWED | MAXIMIZED,
hwnd, NULL, NULL, "%s %s%s%s", ad->info->test,
needs_quoting(ad->arcname) ? "\"" : NullStr,
ad->arcname,
needs_quoting(ad->arcname) ? "\"" : NullStr);

Where is the best place to do a check for?

Since the check always needs to be done, it's generally better to do it in the function.


Last modified 17 years ago Last modified on Aug 25, 2007, 11:32:29 AM