PellesC 8 32 rc1 bugs ?

[TimoVJL]

Thank's Pelle for new version.

PellesC 8 32-bit rc1 debugger crash at start.

Windows 7 SP1 64-bit OS.

EDIT:
Just too big MaxFileSize, it was 1073741824 in xml-file.

WSDK v7.1 uuid.lib
POLINK: fatal error: Unknown kind (0x1510) of CodeView symbol in object 'windowscodecs.lib(guids.obj)'.

When debugging COM code debugger runs to end from first interface call,
except when Show disassembly is on.

Debuggers are unstable, lot of crach?

DbgError2.png from dbginfo.dll Assert error.

poide.exe doesn't open 32/64 bit workspace/projects any more

pocrt.dll
POLINK: error: Unresolved external symbol '___crt_abort'.

[JohnF]

I've tried it both for 64 and 32 bit debugger, all seems ok.

Thank you Pelle.

John

[Bitbeisser]

Just ran a couple of quick checks and it worked fine for me (on Windows 8.1 64bit).

Just that all the previous installations IDE settings got wiped out is a bit anoying... 

Ralf

[Pelle]

Thank's Pelle for new version.

Thanks.

WSDK v7.1 uuid.lib
POLINK: fatal error: Unknown kind (0x1510) of CodeView symbol in object 'windowscodecs.lib(guids.obj)'.

I have seen this code from MS Tools, but I don't know what it means. Undocumented, like all new CodeView stuff.

When debugging COM code debugger runs to end from first interface call,
except when Show disassembly is on.

I don't use COM all that much, so I havn't seen this. I think the problem may be that I don't want to single-step the processor through API calls, since that can take forever, so I need to "cleverly" place internal breakpoints (INT3). There may be a problem with that here. I will see what I can do.

Debuggers are unstable, lot of crach?

I will look at it.

poide.exe doesn't open 32/64 bit workspace/projects any more

poide is stricter about not opening 64-bit Project types. Check POC_PROJECT_TYPE: a number >= 10 means it's for 64-bit Windows.

[TimoVJL]

When debugging COM code debugger runs to end from first interface call,
except when Show disassembly is on.

I don't use COM all that much, so I havn't seen this. I think the problem may be that I don't want to single-step the processor through API calls, since that can take forever, so I need to "cleverly" place internal breakpoints (INT3). There may be a problem with that here. I will see what I can do.

Simple example

Code: [Select]

#define UNICODE
#define WIN32_LEAN_AND_MEAN
#include <windows.h>
#include <ole2.h>

#pragma comment(lib, "user32.lib")
#pragma comment(lib, "ole32.lib")

CLSID const IID_IScriptControl = { 0x0E59F1D3, 0x1FBE, 0x11D0, {0x8F, 0xF2, 0x00, 0xA0, 0xD1, 0x00, 0x38, 0xBC} };

TCHAR *szAppName = TEXT("MSTest");

int main(int argc, char **argv)
{
HRESULT hr;
GUID clsid;
IDispatch *pISC = NULL;

hr = CoInitialize(NULL);
hr = CLSIDFromProgID(L"MSScriptControl.ScriptControl", &clsid);
if (hr)
MessageBox(0, TEXT("Error CLSIDFromProgID()"), szAppName, 0);
else {
hr = CoCreateInstance(&clsid, NULL, CLSCTX_ALL, &IID_IScriptControl, (void **)&pISC);
if (hr)
MessageBox(0, TEXT("Error CoGetClassObject()"), szAppName, 0);
else {
//MessageBox(0, "OK", szAppName, 0);
pISC->lpVtbl->Release(pISC); // gone to end
pISC = NULL;
}
}
CoUninitialize();
return 0;

WSDK v7.1 uuid.lib
POLINK: fatal error: Unknown kind (0x1510) of CodeView symbol in object 'windowscodecs.lib(guids.obj)'.

I have seen this code from MS Tools, but I don't know what it means. Undocumented, like all new CodeView stuff.

can you just ignore it when linking ? (#define LF_NESTTYPE_V3  0x1510 )

[Pelle]

Thanks TimoVJL, I will look at it right away...

[Pelle]

can you just ignore it when linking ? (#define LF_NESTTYPE_V3  0x1510 )

Sorry, missed this before. Can't you just ignore linking with files containing unknown CodeView symbols?
I can't really pick and choose debug symbols; other items may reference the unknown type, for example.

Regarding COM: tricky - the debugger ends up in a system function with no debug info, so it has to assume things about the stack frame (to get at the return address). I have a hack more than a fix, but I think it will have to do for now.

Regarding debugger crash #1: very unlikely crash site, but I guess it could happen. Maybe.

Regarding debugger crash #2: this one looks impossible. What exactly did you do to get this?

[TimoVJL]

Regarding debugger crash #2: this one looks impossible. What exactly did you do to get this?

Just start debugging with poide.exe when Add-In dbginfo.dll was loaded in Win7 SP1 64bit and MaxFileSize in xml was far too big.