EntityFactory constructor loop v2.6

Posts   
 
    
El Barto
User
Posts: 64
Joined: 09-Nov-2006
# Posted on: 17-Jun-2008 21:24:46   

I've upgraded my project today from LLBLGen v2.5 to v2.6. I'm using the adapter type. All went well untill I tested a particular page of the application. This page crashed my WebDev webserver. After I restarted the application in debug mode I got an exception but no location where the exception occured. The exception is this: An unhandled exception of type 'System.StackOverflowException' occurred in mscorlib.dll. The event log messages on crashing the WebDev server couldn't push me either in the right direction. After several hours trying to locate the area where the exception occured I finally noticed that the EntityFactory constructor of a particular entity in the EntityFactories.cs is called time after time. Breaking on this line in debug mode doesn't reveal any stacktrace. For the moment I don't have any clue about the next step to resolve this issue. I know this description is a very limited amount of information but I have no idea where this problem could be related too. This particular page of the application was fine before the upgrade. I've made a fresh install of LLBLGen and opened the llblgen project in v2.6. I've regenerated all code and copied the new runtime libraries in the project.

Can anyone please push me in a direction where I can continue to narrow down to the cause of this problem?confused

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39614
Joined: 17-Aug-2003
# Posted on: 17-Jun-2008 22:59:06   

Could you at least post some code what's going on in the page, and when exactly it happens (e.g. when you click a button or when you first show the page etc. ) and the code which follows the action which triggers the stackoverflow?

If a factory is called time after time, how did you detect that? Could you check the Call stack window in vs.net to see which routines called that factory?

Frans Bouma | Lead developer LLBLGen Pro
El Barto
User
Posts: 64
Joined: 09-Nov-2006
# Posted on: 18-Jun-2008 10:33:25   

To be honest I'm not sure what code to give you. All code runs fine untill the pageload event from the page and all its webusercontrols is finished. Right after the pageload event and before the prerender event this error occurs.

I've detected this problem by setting a breakpoint on the page load of the containing page. After a numb finger and a worn out F11 key cry I noticed this factory constructor is called time after time.

I've attached several screenshots of the code in debug mode. As you can see on the top screenshot the callstack only indicates [External Code]. I don't know how I can find the real callstack. Any suggestion? The second screenshot is just before the exception and the last one after on tap on the F5 key.

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39614
Joined: 17-Aug-2003
# Posted on: 18-Jun-2008 10:58:08   

What you can do is this: VS.NET: Debug menu -> Exceptions. In the Common Language Runtime Exceptions, locate System.StackOverflowException. (use Find at the right). Then check the 'Thrown' checkbox (it's a very slow dialog, so clicking isn't immediately checking it). Then run the website, and attach the debugger in vs.net with cntrl-alt-p -> attach to process.

You then navigate to the page and the exception should be thrown but you also should get a break in the debugger.

In the Call Stack window, right click 'Non-user code' and select 'show non-user code'. The stack should show you what code calls what. It might be useful to use the debug build of the ORMSupportClasses dll (located in the runtimelibs folder).

Frans Bouma | Lead developer LLBLGen Pro
El Barto
User
Posts: 64
Joined: 09-Nov-2006
# Posted on: 18-Jun-2008 11:37:07   

Ofcourse, the debug build. Sorry, my bad flushed

This time the stacktrace is indeed clear on it. I've attached screenshots of the stacktrace of the first 5 hits on the factory constructor. After these the stacktrace becomes predicatable for subsequent hits.

I gues this info is far more usefull.

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39614
Joined: 17-Aug-2003
# Posted on: 18-Jun-2008 11:52:16   

This indeed looks like something I can work with, thanks simple_smile

I'll look into the issue.

Frans Bouma | Lead developer LLBLGen Pro
Otis avatar
Otis
LLBLGen Pro Team
Posts: 39614
Joined: 17-Aug-2003
# Posted on: 18-Jun-2008 12:17:29   

I think I found it. If the collection is null, it has to create it, hence the call to the routine to create it. However, even if if the collection wasn't null, it always set the entityfactorytype, which caused a change event to be raised. This was unnecessary because if the collection was already there, it shouldn't do anything (this routine is required for the new nocache feature)

I've attached a new build for you test.

Frans Bouma | Lead developer LLBLGen Pro
El Barto
User
Posts: 64
Joined: 09-Nov-2006
# Posted on: 18-Jun-2008 12:27:17   

This solves the problem indeed.

Thank you very much for the quick solution. smile