TAutoObjectFactory.Create causes A/V under Win64

[Useful Wiki Links]

•    Downloads
•    Daily Snapshots
•    Wiki
•    Bugtracker
•    Developer Blog
•    Mailing List
•    IRC channel
•    Follow us on Twitter
•    Free pascal
•    Other languages
•    Useful Wiki Links
•    FAQ
•    Project Roadmap
•    Getting the Source
•    Screenshots

Advanced search

PeaZip 3.0 file and archive manager
Other languages
RC1 of FacturLinEx 2.0
Kelime Ezberim v1.2 (Word Memorizing NOT:Turkish program )
sQueryDNS a tool for Query DNS Servers

[jagorath]

Hello, has anyone used TAutoObject automation under Win64?

I'm using fpc 2.5.1 (trunk) and it compiles and registers fine using regsvr32 with just a TLB, no implementation of the objects.  But when I add an interface implementation inheriting from TAutoObj and implement it using TAutoObjectFactory.Create, regsrv32 fails with an A/V.

In an attempt to diagnose the problem, I downloaded the ComTests.zip that I found on the bug tracker and it fails under Win64.  Using the custom regsrv32 project that comes with it compiled under Win64, I traced the error to the LoadLibrary call that returns an error code 6.  This code according to MSDN means "Library required separate data segments for each task".

Has anyone any suggestions as to how to fix this?  Many thanks in advance.

[dmitry]

Have you tried to add some logging to the to the initialization code that registers the class?
Man, we could really use a debugger that allowed to debug dlls from within Lazarus...

[marcov]

I investigated some COM problems on win32 today, and talked with FPK about this, and these are my conclusions

- FPC (win32/64) doesn't use SEH window's own stack wind/unwinder, but an own portable scheme.  Possibly regsvr32 requires this. In M. Spillers tests, there was an app that did the same things as regsvr32, but had the benefit of console output. See what it does.
- Also the safecall mechanism is not complete, the handlesafe* method of tobject is not called.

The not using of SEH has two possible disadvantages: (besides the win64 specific problems you mention, which are maybe fixable)
- problems with COM/CPU/windows exceptions (opposed to own ones) passed by SEH
- problems with exceptions over module borders. (specially heterogenous)

[dmitry]

I had no problem with TAutoObject etc on 32 bit.
Safecall is also manageble, the only problem I had is that it always returned DISP_E_ERROR instead of a particular error code raised by an OLE exception.
64 bit on the other hand is completely broken - safecall works only as long as no exceptions are raised. Raising any exception produces an access violation when RTL tries to free the exception object. I am still debugging...

[jagorath]

Sorry didn't see the posts earlier - thanks for the update and the hard work you guys are doing.

[marcov]

About a week ago, Paul worked on Safecall. Make sure you are up to date before retesting

[dmitry]

The changes that Paul made seem to work great for me.

[jagorath]

I will update and test with my code later today and report back.

[jagorath]

TAutoObjectFactory.Create did not work for me, still produces A/V.  TComObjectFactory does however work.

I've experienced a lot of flakiness with it - sometimes regsvr32 succeeds, sometimes it fails, apparently randomly.  Also my test application that uses the com object fails randomly too.

It could be a problem with my fpc setup as I've just updated lazarus and fpc to Head - I'm not sure what is going on.

[dmitry]

You really need to add some logging to your code to see where the error is raised.
Have you tried to sprinkle your code with OutputDebugString() and then run DebugView from SysInternals?

[jagorath]

I can do that, I know for sure that something in TAutoObjectFactory.Create is causing regsrv32 to crash. 

The next step is to put some OutputDebugStrings calls in the fpc source, specifically TTypedComObjectFactory.Create to see what is going on.  I haven't tried to debug the fpc source before, If I put the calls in there do I have to recompile fpc and lazarus for the changes to take effect?

Cheers, Alan

[jagorath]

Hold up, I've got a bit further without having to recompile the laz or fpc sources. 

It seems that ComServer.TypeLib was unassigned in the call to TAutoObjectFactory.Create.  I figured this was because the tlb was not being linked in to the exe, so I added {$R .TLB} to the lpr.  This is a TLB that was generated from Delphi, so there must be some stuff in it that fpc doesn't like because it can't compile it.  The detailed compiler output is -

Compiling resource C:\Users\Alan\Documents\Projects\MarketBuilder\MarketBuilder Lib\MarketBuilderLib.TLB

Error!

Do tlb's have to be modified somehow when moving to fpc?

I have to say thanks for the OutputDebugString + SysInternals tip, it sure is handy for debugging dlls.

[dmitry]

{$R .TLB} should be fine.
The TLB is not compiled in any way by the compiler, why does it try to compile it? Something is wrong; are you sure you did not specify it as one of the source files?

[Paul Ishenin]

I can't find how tlb resource is included in the fcl-res sources. I will look at it tomorow to be sure regards tlb handling.

[jagorath]

I didn't specify it as a source file, I think it means it is trying to link it rather than compile it. 

Perhaps it is a 32-bit resource and it can't link it into a 64-bit application, in which case a way would need to be found to extract a 64-bit tlb from the original Delphi 32-bit dll.

[Today]

• SQLQuery1.Update Problems... by Kizbits2000 [Today at 03:06:07 am]
• ANY guide to Lazarus Data... by clauslack [Today at 12:38:05 am]
• Lazarus - does not auto i... by abmservice [July 30, 2010, 08:53:58 pm]
• function error by skaner1900 [July 30, 2010, 08:28:03 pm]
• basics of database design by eny [July 30, 2010, 08:27:26 pm]
• LazReport : dates format by tintinux [July 30, 2010, 08:21:31 pm]
• Beginner Question by tintinux [July 30, 2010, 07:56:44 pm]
• Multithreaded Application by Laksen [July 30, 2010, 07:03:01 pm]
• Prioritary cross-PDA APIs... by IndianaJones [July 30, 2010, 04:09:53 pm]
• What database is the Laza... by JD [July 30, 2010, 02:42:00 pm]