BSTR returns invalid characters when multiple event sinks are used
-
Hi I have a component implementing a proprietary protocol (say, Protocol.dll)and does the communciation over serial port. I have defined ATL objects for each type of packet, and nearly all has a property called "description" which returns a BSTR. One ATL object encapsulates the serial communication. So I can set the baud rate, port number etc. A connection point event is defined corresponding to each packet that may arrive to the PC (from the device). Say ProtocolPkt1, ProtocolPkt2, ProtocolPkt3 etc. Now we typically use 2 serial ports. One that does proper protocol communciation and another that dumps trace staements. To take care of the trace statements I have one event defined (LogData) in the same event interface described above. I have an application (say Mainwindow.exe) that uses the above component, connects to both the ports and has separate event sinks to handle the 2 ports separately. The protocol data and the log data coming from the 2 ports are to be shown in separate windows. Whenever an event notifies that log data is received it is simply dumped in a window. Whenever any event notifying any of the protocol packets is received, the corresponding packet is created from the bytes received in the event, interpreted and displayed. Now onto the problem. When some protocol packets are received, the description property has to be called. When both the ports are connected the log data comes fine. But when the description property of say ProtocolPkt1 event is called, the BSTR returned is prefixed with some log string that came in the LogData event. Further the application displays a crash when it is closed. Some more observations. 1. This does not happen when the BSTR returned is very short. Typically only when the string returned is long and computed in some for loop, does this corruption occur. 2. This does not happen when I use the debug version of Protocol.dll. I hope I have made myself clear. If any information is required please let me know. Any pointers that can help me proceed would be greatly appreaciated Thanks aby
-
Hi I have a component implementing a proprietary protocol (say, Protocol.dll)and does the communciation over serial port. I have defined ATL objects for each type of packet, and nearly all has a property called "description" which returns a BSTR. One ATL object encapsulates the serial communication. So I can set the baud rate, port number etc. A connection point event is defined corresponding to each packet that may arrive to the PC (from the device). Say ProtocolPkt1, ProtocolPkt2, ProtocolPkt3 etc. Now we typically use 2 serial ports. One that does proper protocol communciation and another that dumps trace staements. To take care of the trace statements I have one event defined (LogData) in the same event interface described above. I have an application (say Mainwindow.exe) that uses the above component, connects to both the ports and has separate event sinks to handle the 2 ports separately. The protocol data and the log data coming from the 2 ports are to be shown in separate windows. Whenever an event notifies that log data is received it is simply dumped in a window. Whenever any event notifying any of the protocol packets is received, the corresponding packet is created from the bytes received in the event, interpreted and displayed. Now onto the problem. When some protocol packets are received, the description property has to be called. When both the ports are connected the log data comes fine. But when the description property of say ProtocolPkt1 event is called, the BSTR returned is prefixed with some log string that came in the LogData event. Further the application displays a crash when it is closed. Some more observations. 1. This does not happen when the BSTR returned is very short. Typically only when the string returned is long and computed in some for loop, does this corruption occur. 2. This does not happen when I use the debug version of Protocol.dll. I hope I have made myself clear. If any information is required please let me know. Any pointers that can help me proceed would be greatly appreaciated Thanks aby
>> 2. This does not happen when I use the debug version of Protocol.dll. Have you tried looking at this article Surviving the Release Version?
"No matter where you go, there your are." - Buckaroo Banzai
-pete
-
Hi I have a component implementing a proprietary protocol (say, Protocol.dll)and does the communciation over serial port. I have defined ATL objects for each type of packet, and nearly all has a property called "description" which returns a BSTR. One ATL object encapsulates the serial communication. So I can set the baud rate, port number etc. A connection point event is defined corresponding to each packet that may arrive to the PC (from the device). Say ProtocolPkt1, ProtocolPkt2, ProtocolPkt3 etc. Now we typically use 2 serial ports. One that does proper protocol communciation and another that dumps trace staements. To take care of the trace statements I have one event defined (LogData) in the same event interface described above. I have an application (say Mainwindow.exe) that uses the above component, connects to both the ports and has separate event sinks to handle the 2 ports separately. The protocol data and the log data coming from the 2 ports are to be shown in separate windows. Whenever an event notifies that log data is received it is simply dumped in a window. Whenever any event notifying any of the protocol packets is received, the corresponding packet is created from the bytes received in the event, interpreted and displayed. Now onto the problem. When some protocol packets are received, the description property has to be called. When both the ports are connected the log data comes fine. But when the description property of say ProtocolPkt1 event is called, the BSTR returned is prefixed with some log string that came in the LogData event. Further the application displays a crash when it is closed. Some more observations. 1. This does not happen when the BSTR returned is very short. Typically only when the string returned is long and computed in some for loop, does this corruption occur. 2. This does not happen when I use the debug version of Protocol.dll. I hope I have made myself clear. If any information is required please let me know. Any pointers that can help me proceed would be greatly appreaciated Thanks aby
Make sure that the code that fires the event manages the life time of the BSTR. I suspect that the first client is releasing the BSTR and hence ur second client sees garbage. For events and BSTR the caller allocates and frees the bstr. if u are using _bstr_t always pass a copy to the event( bstrVar.copy()) Hope this helps.. prashu
-
Make sure that the code that fires the event manages the life time of the BSTR. I suspect that the first client is releasing the BSTR and hence ur second client sees garbage. For events and BSTR the caller allocates and frees the bstr. if u are using _bstr_t always pass a copy to the event( bstrVar.copy()) Hope this helps.. prashu
Hmm.. never send a copy of a BSTR to a COM method. That means that the method is responsible for cleaning up the string. This however is against COM rules, as [in] parameters MUST be managed by the caller. If the string has to be marshalled through the method call, then the string passed in will be lost (memory leak), and the callee will free a bstr which it does not own (the marshaller owns it). Thus, if you are using a _bstr_t or a CComBSTR, pass the BSTR pointer (or adress of if passing as an [out] argument) managed by these classes. [in] parameters are managed by called [out] parameters are allocated by callee, and passed for ownership to caller -- Ich bin Joachim von Hassel, und ich bin Pilot der Bundeswehr. Welle: Erdball - F104-G Starfighter