problem building with msvc

[revelator]

the C compiler fails to build with msvc 2015 and 2017 "error: failed to open message resource file" msvc 2013 builds that part but fails further down the line with ICU because it does not have char16_t. more errors crop up further down the line with msvc 2013 also.

Would be nice with a more descriptive error, but atleast i found out that the step that fails is creating code386.gh.

[jmalak]

this code is buggy, long time unmanaged

[revelator]

hmm must be an old leftover from watcom 11. So it does call the same dll well thats interresting since rc.exe does not crash.

[revelator]

heh actually it calls wrc directly with ms syntax

define RESCOMPILER "wrc"

also the dll works fine from the ide, but crashes when wrc is executed directly.

[jmalak]

in each bld/mstools/... are gml subdirctory where is ms.gml file describing wrapper commad line options (MS syntax) there are translat.c which contains translation from MS syntax to OW tools syntax.

[jmalak]

I am lost now. What you mean by "crashes when wrc is executed directly"

[revelator]

sorry got a little offtopic with the mstools.

'''C:\Watcom>wrc -h The instruction at 0x0024b797 referenced memory at 0x00000010. The memory could not be read. Exception fielded by 0x004037a0 EAX=0x00000000 EBX=0x00000000 ECX=0x00000000 EDX=0x0003c600 ESI=0x0003c600 EDI=0x00320335 EBP=0x00000000 ESP=0x0018fab8 EIP=0x0024b797 EFL=0x00010206 CS =0x00000023 SS =0x0000002b DS =0x0000002b ES =0x0000002b FS =0x00000053 GS =0x0000002b Stack dump (SS:ESP) 0x00320335 0x00000000 0x00000000 0x00235861 0x00320335 0x00000000 0x00000000 0x0024f70a 0x00000029 0x0025cee4 0x00000000 0x0024f6e0 0x00320335 0x0024c6c9 0x0025c450 0x00000029 0x0024c62d 0x20656d61 0x74706f7b 0x736e6f69 0x00320335 0x75000600 0x69000300 0x0025c450 0x20000000 0x00000001 0x00282416 0x00000000 0x0024c6a5 0x00000400 0x0025c450 0x00247f2a 0x0018fb64 0x00000029 0x002316a0 0x64657403 0x00000004 0x20202020 0x00008008 0x00000029 0x0018fbd4 0x00000000 0x0023177e 0x0018fb78 0x00282416 0x0018fb00 0x00235da0 0x00000029 0x00000068 0x0032032d 0x0018fbd4 0x00235e11 0x0024c600 0x00235ad8 0x00000010 0x00000801 0x00000001 0x00320319 0x0018fbd4 0x0032032d 0x00282415 0x0018fbd4 0x00236e3e 0x00000003 0x00000002 0x0024fd01 0x00000002 0x00409078 0x00320315 0x00000002 0x00237140 0x00000000'''

or

'''C:\Watcom>wrc Open Watcom Windows and OS/2 Resource Compiler Version 2.0 beta Dec 16 2018 02:49:47 (32-bit) Copyright (c) 2002-2018 The Open Watcom Contributors. All Rights Reserved. Portions Copyright (c) 1993-2002 Sybase, Inc. All Rights Reserved. Source code is available under the Sybase Open Watcom Public License. See http://www.openwatcom.org/ for details.

The instruction at 0x0043b797 referenced memory at 0x00000010. The memory could not be read. Exception fielded by 0x004037a0 EAX=0x00000000 EBX=0x00000000 ECX=0x00000000 EDX=0x0003c600 ESI=0x0003c600 EDI=0x003d0335 EBP=0x00000000 ESP=0x0018f844 EIP=0x0043b797 EFL=0x00010206 CS =0x00000023 SS =0x0000002b DS =0x0000002b ES =0x0000002b FS =0x00000053 GS =0x0000002b Stack dump (SS:ESP) 0x003d0335 0x00000000 0x00000000 0x00425861 0x003d0335 0x00000000 0x00000000 0x0043f70a 0x0000006a 0x0044cee4 0x00000000 0x0043f6e0 0x003d0335 0x0043c6c9 0x0018f9d4 0x0000006a 0x0043c62d 0x0018f8e0 0x00000003 0x00441c00 0x003d0335 0x00000600 0x00000700 0x0018f9d4 0x00000000 0x00000001 0x00409078 0x00000000 0x0043c6a5 0x00000100 0x0018f9d4 0x00437f2a 0x00000007 0x000000ff 0x004391d3 0x575c3a43 0x6f637461 0x49425c6d 0x5c544e4e 0x2e637277 0x00657865 0x0018f97c 0x00000002 0x751c124c 0x00000000 0x00000000 0x0018fba4 0x00000002 0x00000002 0x0018f934 0x751a3046 0x00000000 0x00000200 0x0018f97c 0x00000002 0x0018f97c 0x00000002 0x00000000 0x00000000 0x00000000 0x0018f958 0x75a2fc9e 0x00000010 0x0018fba4 0x00000002 0x00000002 0x0018fb80 0x75a2fee7 0x0018fba4 0x00000002 0x0018f978 0x0018f97c'''

ill try running a resource file through it for good measure to see if it also crashes there.

[revelator]

yep also crashes on a resource file :/

[jmalak]

OK, now we are on the same wave. If wrc is working from IDE then DLL part is OK (IDE call DLL directly without EXE part). Problem should be in driver part (wrc.exe). It is small code in maindrv.c it calls interface functions for DLL part. Try to debug it.

[revelator]

will do, might take a while since ill have to rebuild everything in debug mode.

[jmalak]

No It is not necessary only WRC is enough.

[revelator]

can i set it locally ?, ok. where might be the best place to set it, makefile or master.mif ?.

[jmalak]

go to bld/rc/rc and run command builder clean next builder build OWDEBUGBUILD=1 It build debug version of wrc

[jmalak]

in directory bld/rc/rc/ntx64.dll you will have wrc which you can debug by WinDBG

[revelator]

ok still have to rebuild a few things since i done a clean on the entire build so it complains about some missing libraries.

[jmalak]

you can recompile only bld/hdr and bld/clib and bld/wres

[revelator]

wrcd.dll!_invoke_watson(const wchar_t const expression, const wchar_t const function_name, const wchar_t const file_name, const unsigned int line_number, const unsigned __int64 reserved) Line 233 C++ wrcd.dll!_invalid_parameter(const wchar_t const expression, const wchar_t const function_name, const wchar_t const file_name, const unsigned int line_number, const unsigned int64 reserved) Line 112 + 0x12 bytes C++ wrcd.dll!_invalid_parameter_noinfo() Line 118 C++ wrcd.dll!common_fseek(crt_stdio_stream stream, const __int64 offset, const int whence) Line 180 + 0x12 bytes C++ wrcd.dll!res_seek(_iobuf fp, long amount, int where) Line 360 + 0x1d bytes C wrcd.dll!WResReadDir2(_iobuf fp, WResDirHead currdir, unsigned char dup_discarded, void fileinfo) Line 367 + 0xe bytes C wrcd.dll!WResLoadString2(WResDirHead dir, handle_info hinfo, unsigned int idResource, char lpszBuffer, int nBufferMax) Line 129 C wrcd.dll!WResLoadString(handle_info hinfo, unsigned int idResource, char lpszBuffer, int nBufferMax) Line 144 C wrcd.dll!GetRcMsg(unsigned int resid, char buff, int buff_len) Line 120 + 0x26 bytes C wrcd.dll!RcIoPrintUsage() Line 246 C wrcd.dll!print_banner_usage() Line 267 C wrcd.dll!RCMainLine(const char opts, int argc, char argv) Line 325 C wrcd.dll!IDERunYourSelf(void hdl, const char opts, wchar_t fatalerr) Line 404 + 0xf bytes C wrc.exe!IdeDrvExecDLL(IDEDRV inf, const char cmd_line) Line 576 + 0x18 bytes C wrc.exe!main(int count, char * args) Line 73 + 0x11 bytes C wrc.exe!__scrt_common_main_seh() Line 288 + 0x22 bytes C++ kernel32.dll!0000000076c859cd()
[Frames below may be incorrect and/or missing, no symbols loaded for kernel32.dll]
ntdll.dll!0000000076ee385d()

in this section

'''bool res_seek( FILE *fp, long amount, int where ) /***/ / Note: Don't seek backwards in a buffer that has been writen to without / / flushing the buffer and doing an lseek since moving the NextChar pointer / / back will make it look like less data has been writen / { RcBuffer *buff; long currpos; int diff; int i;

if( hInstance.fp == fp ) {
    if( where == SEEK_SET ) {
        return( fseek( fp, amount + WResFileShift, SEEK_SET ) != 0 ); // crashes here with invalid data
    }
    return( fseek( fp, amount, where ) != 0 );
}
i = RcFindIndex( fp );
if( i >= RC_MAX_FILES ) {
    return( fseek( fp, amount, where ) != 0 );
}

buff = RcFileList[i].Buffer;

currpos = res_tell( fp );

if( buff->IsDirty ) {
    switch( where ) {
    case SEEK_CUR:
        amount += currpos;
        where = SEEK_SET;
        /* FALL THROUGH */
    case SEEK_SET:
        /* if we are seeking backwards any amount or forwards past the */
        /* end of the buffer */
        if( amount < currpos || amount >= currpos + ( RC_BUFFER_SIZE - buff->Count ) ) {
            if( FlushRcBuffer( fp, buff ) )
                return( true );
            return( fseek( fp, amount, SEEK_SET ) != 0 );
        } else {
            diff = amount - currpos;
            /* add here because Count is chars to left of NextChar */
            /* for writing */
            buff->NextChar += diff;
            buff->Count += diff;
        }
        break;
    case SEEK_END:
        if( FlushRcBuffer( fp, buff ) )
            return( true );
        return( fseek( fp, amount, SEEK_END ) != 0 );
    default:
        return( true );
    }
} else {
    switch( where ) {
    case SEEK_CUR:
        amount += currpos;
        where = SEEK_SET;
        /* FALL THROUGH */
    case SEEK_SET:
        /* if the new pos is outside the buffer */
        if( amount < currpos + buff->Count - buff->BytesRead || amount >= currpos + buff->Count ) {
            if( FlushRcBuffer( fp, buff ) )
                return( true );
            return( fseek( fp, amount, SEEK_SET ) != 0 );
        } else {
            diff = amount - currpos;
            /* subtract here because Count is chars to right of NextChar */
            /* for reading */
            buff->Count -= diff;
            buff->NextChar += diff;
        }
        break;
    case SEEK_END:
        if( FlushRcBuffer( fp, buff ) )
            return( true );
        return( fseek( fp, amount, SEEK_END ) != 0 );
    default:
        return( true );
    }
}
return( false );

}'''

[revelator]

seems to be fseek triggering an exception, strangely it seems to think its a bad memset.

[revelator]

going to try building it with the watcom compiler itself to see if that changes anything.

[revelator]

well that was a no go, still crashes so its not something related to the compiler used. unfortunatly the debugger cannot give me any clues as to where this crash originates, it just sends me on a wild goose chase through a ballpark of debugging checks in the crt. The only result so far has been that that it is crashing in res_seek in fseek specifically with what it describes as a bad ptr.

[revelator]

Im going to do a full build with the msvc analyzer turned on, if you want ill upload boot.log when its done building, it should contain the output of any problems detected by the analyzer. Might help getting some insight as to what causes this.

[revelator]

i can also upload the debug builds of wrc.exe if you want them.

[jmalak]

Thanks for crash log. Now I localized source of problem. There is problem that after message system initialization it is cleared by global variable initialization which clean already initialized message system. I will fix it ASAP.

[jmalak]

it should be fixed by 82512d5bf07d5a26e02a70d6616a9bbb9a992ca9 commit

[revelator]

np m8 glad you could get any details out of that mess :)

[revelator]

works fine now :)