0

I have a VB.NET application that seems to run perfectly in the VS2012 IDE. It processes thousands of records. When I compile it for release it will process random numbers of records (<200) and dies with "Object reference not set to an instance of an object."

It always dies in an external C++ DLL that I call which also does call backs to my code. The call backs from unmanaged code require the use of delegates. I am not familiar with the intricacies of delegates never having to use them before.

In my research I notice that they are used for initiating multi-threading. Is it possible that I have unintentionally made my application multi-threading?

Here is the syntax I am using;

Public Delegate Sub EditsMessagerHandlerDelegate(ByRef objThis As IntPtr, _
                                              ByVal strEditTag As String, _
                                              ByVal strEditName As String, _
                                              ByVal strAdminCode As String, _
                                              ByVal strErrorType As String, _
                                              ByVal strMessage As String)
    Dim objEditsMessagerHandler As New EditsMessagerHandlerDelegate(AddressOf EditsMessagerHandler)
    Dim ptrEditsMessagerHandler As IntPtr = Marshal.GetFunctionPointerForDelegate(objEditsMessagerHandler)
    Edit_RunEdits(_intsmfID, _strEditSetTag, _strEditLayoutTag, strNAACCRRecord, _
                                    EE_NOSKIP, intErrCount, ptrThis, ptrEditsMessagerHandler)

My questions;

Will this cause the app to multi-thread?

Would an unintentionally multi-threading app cause the error I am experiencing?

How can I force it to all run in the same thread?

I cannot control the C++ DLL, nor can I see the source.

Edit:

This is not a question about "Object reference not set to an instance of an object." This is a question about whether using p/invoke will inadvertently cause multithreading.

I have read the linked article as well as many others, and none of the issues raised seem to apply. Please do not willy nilly call something a duplicate because you believe the wrong question is being asked. If you have an answer to my specific questions please reply.

I was requested to post a stack trace of the problem, here it is;

System.NullReferenceException: Object reference not set to an instance of an object.
   at Microsoft.VisualBasic.CompilerServices.Symbols.Container.InvokeMethod(Method TargetProcedure, Object[] Arguments, Boolean[] CopyBack, BindingFlags Flags)
   at Microsoft.VisualBasic.CompilerServices.NewLateBinding.ObjectLateGet(Object Instance, Type Type, String MemberName, Object[] Arguments, String[] ArgumentNames, Type[] TypeArguments, Boolean[] CopyBack)
   at Microsoft.VisualBasic.CompilerServices.NewLateBinding.LateGet(Object Instance, Type Type, String MemberName, Object[] Arguments, String[] ArgumentNames, Type[] TypeArguments, Boolean[] CopyBack)
   at ACE.OraEditsLib50.processRecord(String strInterRecordEditsName, OracleConnection objConnection) in I:\FCDSApps\OraEditsLib50\OraEditsLib50\OraEditsLib50.vb:line 299

Interestingly enough, line 299 is not the last VB line it executes. I have verified that the fuction call in a different class at that line is executed as well as an additional 10-15 lines of code all the way up until it calls the C++ DLL. EDIT again

While the "duplicate" message above did not solve my problem, the issue my program was having was not related to multi-threading.

I was defining objects and pointers to my delegates in local variables in a method within a class. I was not properly disposing of the objects & pointers before exiting the methods within the class. To resolve the issue I moved those objects to "private" variables as they would never change over the life of the instantiated class, and my problem went away.

One of the other members (I would mention his name but he may not want others to assume he would provide the help he provided to me) here actually looked over some of my code and made the suggestion that fixed the problem.

Paul Stearns
  • 856
  • 9
  • 30
  • No, but you get a null pointer exception, so probably, you are sending a null value. Delegates are just methods that can be invoked. You should probably check for which output your program crashes, like add a logger to say which data is being processed, maybe you can find it out like that – Icepickle Jun 17 '17 at 23:07
  • 1
    Delegates are used in managed threads, but they are not inherently multi-threaded and do not in and of themselves cause code to be executed in a different thread. That said, `NullReferenceException` _also_ does not imply multithreading. There are lots of mundane reasons you could get that exception. The first step is to debug. If you want to ask for help here, you need to provide a good [mcve] that reliably reproduces the problem, as well as a detailed explanation of what debugging you've done so far and what _specifically_ you need help with. – Peter Duniho Jun 17 '17 at 23:28
  • @PeterDuniho Debugging so far, 10-15 hours. The problem cannot be boiled down to a simplistic example. What I think I know is that the problem occurs sometime after I call a C++ DLL that I do not have the source code nor the pdb file for and before it returns control back to my module. I also know I have specific set of data arranged in a specific order and it dies on different records each time. I also know that it successfully processes thousands of records when run in the VS IDE. It will also process between 6 and 185 records when running from the "release" code. – Paul Stearns Jun 18 '17 at 03:46
  • 1
    _"Debugging so far, 10-15 hours"_ -- We don't need to know nor care how much time you spent. We need to know _what_ you have done. _"The problem cannot be boiled down to a simplistic example"_ -- to be a useful question on Stack Overflow, you need to be able to provide a good [mcve]. If you cannot, then your question is not a good fit for Stack Overflow. In any case, we have successfully ruled out the one guess you made, because your assumption was wrong. You haven't provided a MCVE, nor even any detail on the exception (e.g. stack trace), so there's nothing more the SO community can do. – Peter Duniho Jun 18 '17 at 04:06
  • @PeterDuniho I am not trying to be difficult. In order to provide a minimal, complete and Verifiable example, I would need to understand what is causing the problem. Were I to understand that, I would probably be able to solve the problem. I will add the relevant part of the stack trace, to the original post. – Paul Stearns Jun 18 '17 at 04:37
  • _"I am not trying to be difficult"_ -- I never suggested you were. I'm only suggesting that your question isn't appropriate for SO. _"In order to provide a minimal, complete and Verifiable example, I would need to understand what is causing the problem"_ -- then your question is highly unusual. Nevertheless, your inability to create a good MCVE does not negate the need for one. There's no reason to expect people with _less_ information than you have, to be able to solve a problem you weren't able to. – Peter Duniho Jun 18 '17 at 04:40
  • 2
    _"blocking my question by incorrectly"_ -- your question is the epitome of those which are duplicates of the canonical `NullReferenceException` question. You have absolutely zero actionable information in the question, other than a statement that a `NullReferenceException` is being thrown. Closing it serves the community, doing plenty of good, by ensuring that your question does not distract from other questions which are answerable. And accusing me of playing God and attempting to command my actions is just plain inflammatory. – Peter Duniho Jun 18 '17 at 05:47
  • Oh, and further more: you continue to state that _"This is a question about whether using p/invoke will inadvertently cause multithreading"_, a question I've already answered. Your theory in that respect is simply erronous and there's no value in keeping a question on Stack Overflow addressing such spurious reasoning. – Peter Duniho Jun 18 '17 at 05:48
  • Hey Paul, the error you are stating says exactly that what we are referring to in the closed question, it is also one of the most common questions around on SO. With the info you have given us, we as community members can only link you there, this is a community that has rules and closing topics because they are obvious duplicates is one of our responsibilities – Icepickle Jun 18 '17 at 05:54
  • @PeterDuniho You commented a potential answer. You blocked the question by calling it a duplicate when it is not. If you wish to answer, then answer, don't post comments. I asked legitimate questions. You ignored the fact that the program works properly in the VS2012 IDE on the same data set but does not work in the released version. How can that be explained or debugged using standard NullReferenceException debugging? – Paul Stearns Jun 18 '17 at 05:56
  • @Icepickle I was asking specific questions about delegates. I was not asking about my underlying problem. If you don't want to answer the questions I ask, why classify it as a duplicate. I spent many hours trying to solve the underlying problem, checking and rechecking my code and all of the variables. This is made difficult due to the fact that everything works in the IDE, but consistently dies in the release version. I feel very confident that it is not a garden variety NullReferenceException, or it would show up in the IDE when I run the same data through the program. – Paul Stearns Jun 18 '17 at 06:04
  • Paul, @PeterDuniho and I don't have that data, we don't even know with which C++ dll you are talking or what it's signature is. The info you have given in your question and the stacktrace both lead us to believe it is a NullPointerException. From where it is coming is impossible to know from the given information. The question about the delegates was replied to in our first 2 comments at once and the updated info in the question still seems to be about the NullReference exception. To be fair to us, we don't even know if your question is winforms, wpf or console. Try to update your question... – Icepickle Jun 18 '17 at 06:11
  • ... so that we can know what you are trying to do, give us a sample of your input/output data, provide the signature of the dll you are talking to and maybe then it becomes more clear to us what might be causing your problem. And just maybe, read [this](https://codeblog.jonskeet.uk/2010/08/29/writing-the-perfect-question/) through about asking questions – Icepickle Jun 18 '17 at 06:12
  • I would love to, but each record is fixed length and 22,000+ bytes long and contains PHI. HIIPA laws are rather sticky about releasing that kind of data. Can you at least answer one question. Is there a way of making sure that a VB.NET program runs in a single thread? – Paul Stearns Jun 18 '17 at 06:17
  • Let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/146982/discussion-between-icepickle-and-paul-stearns). – Icepickle Jun 18 '17 at 06:19

0 Answers0