4

I am doing a project where I am loading several assemblies during runtime, for each of those assemblies I use reflection to find some specific classes, instantiate them and calling their methods. All this is working fine, but for some of the calls the process encounters a stack overflow which terminates my entire program. I don't have any control over the source code of the assemblies I am loading so I cant change the code I'm executing.

What I have tried to solve the problem:

  1. I assign a thread to do the invocation of the methods and tried to
    abort the thread after a timeintervall(I know that this is bad practice but I cant change the code to terminate friendly). This however doesn't work, I think the thread is to busy "stackoverflowing" to handle the Abort-call.

  2. Ive tried reducing the actual memory the thread has access to, this is not even a solution because you cant catch the stackoverflow-exception so my program terminates anyway (just quicker)

Questions:

  1. Can a thread be to busy to be aborted? Is there some way to abort a thread that is having this behaviour?
  2. How can we call code (that we don't have any control over) in a good way?

Thanks in advance!

Disillusioned
  • 14,635
  • 3
  • 43
  • 77
user579089
  • 185
  • 3
  • 8

1 Answers1

6

The recommended procedure in case of "opaque code" is to actually fork a new process and start it. That way you gain two benefits:

  1. If it fails by itself, it's isolated and won't take your main application down as well.
  2. You can safely kill it and it won't cause as much trouble as an aborted thread.
Tudor
  • 61,523
  • 12
  • 102
  • 142
  • how would you access the loaded classes from Process1 in this case? – GETah Apr 24 '12 at 17:46
  • If we load the assemblie in a new process, I need to get an instance from that process and pass it to another instance (that will perform some test on the instance) in the main process, is tbis even possible? I think this is the same question as @GETah ask above. – user579089 Apr 24 '12 at 21:19
  • Remember that you are building the other process. Simply create a process that acts as a front-end for your main process. The child process will load the assembly and then expose some commands (through some RPC for example) that the main process can then use to query information. If the child then dies because of stackoverflow, the parent is not affected. – Tudor Apr 24 '12 at 21:23
  • @Tudor Excellent suggestion, +1. One might think of using WCF for inter process coms – GETah Apr 24 '12 at 21:51