search

twinbasic / twinbasic

284 stars 23 forks source link

TypeInfo-Parsing crashes the tB-Compiler-Process #128

Closed vbRichClient closed 3 years ago

vbRichClient commented 3 years ago

Describe the bug Compiler gets into a "crash-reload-cycle" when certain TypeLibs are checked in...

To Reproduce E.g. check-in:

Expected behavior An error-message would be nice (e.g. about the "last attempted part to parse" in the given typlib). Also some way to keep the Project in a "usable state" - removing the offending lib-reference... (no matter if I press "Ok", in the "cycling-Dialogs" or "Cancel" - the "offending Lib-CheckIn" remains in the project, without any chance to get rid of it ... and the "cycle" starts again)...

Screenshots

Desktop (please complete the following information):

WaynePhillipsEA commented 3 years ago

Hmm can't repro at the moment. Added both the Image-Acquisition lib and RC6 without this problem.

WaynePhillipsEA commented 3 years ago

Any chance you could attach the project files? (or send by email)

bclothier commented 3 years ago

Regarding this part:

Also some way to keep the Project in a "usable state"

Maybe consider tracking the cycle and at a certain threshold, automatically and temporarily check the project setting's "Disable compilation"?

WaynePhillipsEA commented 3 years ago

@bclothier This is already in place. If the compiler crashes 5 times within 2 minutes, it will disable the compilation stage temporarily. You can test this by calling CrashMe from the debug console 5 times.

I don't think the compiler is actually hard-crashing in this case. I suspect that something in the LSP implementation is causing the LSP to reset on the VS code side, and then parsing keeps restarting when the LSP auto-reconnects. I can look at adding a similar rate-limit to that auto-reconnect point, once I've confirmed the issue.

My guess is that this is probably something to do with the new attributes support.

vbRichClient commented 3 years ago

http://vbRichClient.com/Downloads/HelloWorldDerived.zip

The above zip has two SubFolders (both Folders contain a now "dead-locking" project):

Not sure, why this happens (have also just started the entire machine, retried again - still not working). Maybe it's a simple "locale"-Problem? (e.g. my "german decimal-point as a comma" or some "Date-readouts", or something)?

Olaf

WaynePhillipsEA commented 3 years ago

I couldn't repro with your projects, but I do remember deleting some locale files in the vs code extension around that release, as I thought they weren't being used yet. Oops. I'm just publishing v0.9.2652 now that I'm hoping may fix it for you.

WaynePhillipsEA commented 3 years ago

Actually, it looks like the Edanmo is crashing, but the RC6 does not (at least with my version of RC6)

vbRichClient commented 3 years ago

Just updated to (reloaded) the newest tB-Version (from within the "normal", working HelloWorld-Project). Then closed all VSCode-instances, restarted from within my 'HelloWorldEdanmo' Folder - the Workspace with the offending Project-Ref via DblClick in Explorer...

The ScreenShot below was taken, after I:

Have also checked in TaskManager at this point - and the twinBasic-Process is gone at that point.

DeadLock

vbRichClient commented 3 years ago

Actually, it looks like the Edanmo is crashing, but the RC6 does not (at least with my version of RC6)

Ahh - good, finally something that behaves "as expected"... ;-)

And yes, I'm already working on some enhancements for the upcoming RC 6.0.9 version, but didn't extend anything in the Interface so far (IIRC... will check again) - but the current RC6-version here works "as always" in the VB6-IDE.

Regards,

Olaf

WaynePhillipsEA commented 3 years ago

v0.9.2653 is being published. It fixes the Edanmo crash on my machine. Hopefully fixes both for you :)

vbRichClient commented 3 years ago

v0.9.2653 is being published. It fixes the Edanmo crash on my machine. Hopefully fixes both for you :)

It did fix both!!! (...and damn, you're fast).

May I ask what the cause was?... (something locale-related)?

Regards,

Olaf

WaynePhillipsEA commented 3 years ago

Thanks for confirming! No it wasn't locale related. There's a (presumably new) tyepdef/alias in the olelib.tlb to a VT_I1 type (signed byte) that was throwing the type library loader off. I've put a temporary fix in, but I'll revisit this tomorrow morning to do a more appropriate fix. Apologies.

vbRichClient commented 3 years ago

Thanks, will now check whether I have something changed ("signed Byte-related") on the RC6-interface...

And no apologies needed...

Perhaps (since you plan to "look at typelib-parsing tomorrow anyways")... I may add something which is not really a "hard bug" - but somewhat related...

Your Intellisense-mappings seem to work for all the "dozens" of RC6-Classes, with one (important) exception: Public New_c As New cConstructor '<- when hovering with the mouse there, I only see "Loading..." - (for a very long time - without any upcoming result).

But that behaviour is something, which I've encountered already from the first tB-versions.

In case I shall shift that over into a "new Issue", just say the word...

Regards,

Olaf

WaynePhillipsEA commented 3 years ago

Just for reference, the olelib.tlb file contains a "typedef char CHAR;", and that alias is referenced only in the exposed DLL entry of PathGetCharTypeA. Due to char being a signed-byte, VBA/VB6 marks that function as restricted, and can't be called. Similarly, twinBASIC now marks this datatype (and other such types) as unsupported, and the function can't be called, as of v0.9.2699.

WaynePhillipsEA commented 3 years ago

Oh, and the intellisense thing should now be resolved in v0.9.2699 too.

vbRichClient commented 3 years ago

Thanks. (just a confirmation, that all is working nicely now - including the intellisense for cConstructor)