Custom Query (122 matches)
Results (19 - 21 of 122)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #20 | fixed | 09-017 Test3UO in Aspen Plus 7.1.1 | Michael Halloran | michelpons |
| Description |
De: Michel PONS via YouSendIt [delivery@…] Envoyé: Wednesday, August 26, 2009 10:48 AM À: technologyofficer@… Objet: File Sent: COLTT09-017.zip
============================================================== De: Michel Pons [technologyofficer@…] Envoyé: Wednesday, August 26, 2009 10:43 AM À: 'Michael Halloran' Cc: 'malcolm.woodman@…' Objet: COLTT 09-017 Test3 in Aspen Plus v7.1.1 Michael, You may want to log this issue through the bug tracking facility on SourceForge. I have not put yet SHMA in copy since I don’t know what is the on-going status with SHMA at this stage. Within Aspen Plus 2006.5 I had logged an issue labeled 917841 that pertained to the fact that the flow property in Aspen Plus was not correctly implemented. This led to defect CQ00319371. I had documented this defect with a dedicated Fortran made UO that did not much except calling on this flow property to show it did not work properly. This defect has been announced as resolved in Aspen Plus 7.1. So I have reset the case in Aspen Plus 7.1 with Cumulative Patch 1. I will post you through yousendit the accompanying material meaning the installer for the UO, the bkp file used to start the case as well as the log files and the screenshots mentioned hereafter. The scenario is rather simple. I start from an Aspen Plus file that presents two material streams (one for input, one for output). The inlet stream is fully configured. I select the Corentin_version3 UO (the CAPE-OPEN UO mentioned above) within the CAPE-OPEN library of UOs available and I drop it on the flowsheet. In Aspen Plus 2006.5 I was able to connect the streams and to launch calculation. In Aspen Plus 7.1.1 the UO looks dead meaning no ports available on the UO so I don’t get any further. I have relogged an issue with Aspentech Support on that one. To try understanding the issue I first logged the scenario with COLTT 1.07 enabled on the UO. To my surprise, with COLTT enabled on the UO, the ports are appearing on the UO and the calculation is fine. I can even check that indeed the flow property is well returned by the MO. So I have an issue with COLTT: it changes the behaviour in between the PMC and the PME. My next step has been to try COLTT 1.08.02 on this case. Here I have also a change a behaviour between the PMC and the PME since the ports are showing up and I may launch the calculation. However I have, within the Calculate method, a debug assertion failure message (see screenshots for that) that I chose to ignore and I have then Aspen Plus miserably crashing. So there is also a different behaviour between 1.07 and 1.08.02. That does not help. I have defined this as being issue COLTT 09-017 in order to track it on my side for the moment. There may be two issues there. One is making the ports appear and the second is the debug assertion failure in 1.08.02. Best regards Michel |
|||
| #21 | fixed | 09-014 GLCC UO in PRO/II 8.3 | michaelhalloran | michelpons |
| Description |
De: Michel Pons [technologyofficer@…] Envoyé: Wednesday, June 24, 2009 10:50 PM À: 'Ahsan Akhtar' Cc: 'Michael Halloran' Objet: COLTT 09-014 Debug and crash for GLCC in PRO/II Pièces jointes: proii_062409_223724.log Ahsan, I have a scenario showing a strange behaviour on COLTT 1.08.02. It involves a UO PMC (GLCC) and PRO/II 8.3. Without COLTT enabled on GLCC UO, the calculation of the UO does not go well and I wanted to look at the log in order to figure out what was going on. However enabling COLTT 1.08.02 on GLCC leads first to a debug assertion error then a crash a bit after instantiating the GLCC UO within the PRO/II flowsheet. In fact I have two crash messages as follows: Microsoft Visual C++ Debug Library Debug Assertion Failed!
Program: C:
File: d: Line: 154 Expression: p!=0 For information on how your program can cause an assertion failure, see the Visual C++ documentation on asserts. (Press Retry to debug the application) Abandonner Recommencer Ignorer I selected « Ignore » and got : Exception Detected Exception code 0xc0000005: EXCEPTION_ACCESS_VIOLATION The thread tried to read from or write to a virtual address for which it does not have the appropriate access. Select Cancel to debug or OK to save the copy and quit. OK Annuler Exception Detected Exception code 0xc0000005: EXCEPTION_ACCESS_VIOLATION The thread tried to read from or write to a virtual address for which it does not have the appropriate access. Select Cancel to debug or OK to save the copy and quit. OK Annuler There is a short log created. It is attached. I have numbered this issue 09-014. Let me know if you need Visual Studio 2008 installed in the VM dedicated to this issue. Best regards Michel |
|||
| #22 | Not Reproducible | 09-015 gOCAPE-OPEN in Aspen Plus | Michael Halloran | michelpons |
| Description |
De: Michel Pons [technologyofficer@…] Envoyé: Tuesday, September 08, 2009 9:09 AM À: 'Michael Halloran'; 'Ahsan Akhtar' Objet: RE: Status of work on COLTT Michael, I will send you through yousendit.com the log file named apmain_082009_125534.log that was the last one made by Ahsan on August 20. Best regards Michel ============================================================ De: Michel PONS via YouSendIt [delivery@…] Envoyé: Tuesday, September 08, 2009 9:08 AM À: technologyofficer@… Objet: File Sent: apmain_082009_125534.zip
============================================================= De: Michael Halloran [michaeljhalloran@…] Envoyé: Monday, September 07, 2009 11:23 PM À: Ahsan Akhtar Cc: Michel Pons Objet: Re: Status of work on COLTT Hi Ahsan, Sorry I must have missed this reply somehow. Thanks for resending it today. Michel, do you have a log for the same run using 1.08.2 with Ahsan's fix applied? I'd like to compare it to the 1.08.2 log that you originally sent. Regards Michael ========================================================== De: Ahsan Akhtar [ahsan.akhtar@…] Envoyé: Monday, September 07, 2009 9:25 AM À: 'Michael Halloran'; 'Michel Pons' Cc: 'Malcolm WOODMAN' Objet: RE: Update Pièces jointes: Status of work on COLTT (42.8 Ko) Michael, I am enclosing my email that I sent to you last Saturday explaining the issue of Aspen Plus (from your email, it looks that you haven't received my email). Regards Ahsan ========================================================== De: Michael Halloran [michaeljhalloran@…] Envoyé: Sunday, September 06, 2009 6:25 PM À: Michel Pons; Ahsan Akhtar Cc: Malcolm WOODMAN Objet: Update Michel, Ahsan, I have committed all my changes - a lot of files updated because of changes to 1) output so that searching for \"error\" only finds actual errors and 2) changes to a lot of header files to remove the causes of complier warnings, so that the build is much cleaner now. I've also updated the solution files and project files, again to clean up the build but to also get the release and debug build configurations correct for building from SourceForge. One consequence of my changes is that it is not so easy to compare a 1.07 file with a file produced from this version automatically - it shows too many differences because many lines of output have changed. It's still reasonable to do by eye I think. I have not committed my change for the persistence interface logger. I have tested with COFE and it seems correct but I would like to hear from Ahsan about the Aspen Plus problem first. I have uploaded the two license files to a new folder called Documentation. Ahsan, these two files have changed since the last .msi was created so the next .msi will need to include these versions. I have started using the TRAC system on SourceForge for recording issues, as we discussed. I've entered the last four that you sent Michel. You can find it here: https://sourceforge.net/apps/trac/cape-openloggin/ Select the View Tickets link and then the Active Tickets report to see the list. All the attachments are uploaded as well. Michel, if you can put future issues in here as well, I'm sure we can arrange for email notifications to be sent. I got them for these four but perhaps that's because I was the raiser. We need to consider whether we want to put of the other already known issues in as well or whether we just start with these 4. I'll send instructions on AnkhSVN shortly. It seems to be working pretty well so far. Regards Michael ========================================================= De: Ahsan Akhtar [ahsan.akhtar@…] Envoyé: Saturday, September 05, 2009 7:32 AM À: 'Michael Halloran' Cc: 'Michel Pons' Objet: RE: Status of work on COLTT Michael, Before answering your query about commenting out the Release call, I would like to mention that I myself was not satisfied with this solution (although it fixed the issue 09-015) and that's why I told Michel during the PCNow session that I would need to discuss it further with Michael for its correctness. Sorry for not discussing the issue before committing the code on sourceforge (I should do it as I also spoke to Michel regarding this fix). I commented out the line \"reinterpret_cast<IPersistStreamInit*>(*ppv)->Release();\" because I noticed that call to InitNew was not present in the log file generated by COLTT despite the fact that COLTT was executing the code block which was returning the pointer to IPersistStreamInit interface. I assumed that COLTT is causing a premature release of IPersistStreamInit interface.To confirm my assumption, I commented out all the code which was caching the IPersistStreamInit pointer returned by QueryInterface except the following two lines:
i.e. I left the code un-commented which was QueryInterface IPersistStreamInit on actual logged component and it worked fine. Then I un-commented all the code except the line with release function call and it also worked fine.I think this is PME (AspenPlus) not release call which is causing reference count issue because the current logic was working fine with other cases as well and also according to COM rules (but I can't explain it as I was not able to debug the case). Please also note that I was not able debug the case in VS2008 and I used message lines to debug the code. I also tried your advice to debug the case which I received in one of your earlier emails. Your revised logic is correct and the previous logic had a defect that you mentioned in your email. Please let me know if I have clarified my point clearly or not? Ahsan ========================================================= De: Ahsan Akhtar [ahsan.akhtar@…] Envoyé: Thursday, September 03, 2009 10:36 AM À: 'Michael Halloran' Cc: 'Michel Pons' Objet: RE: Status of work on COLTT Michael, I will send you response to this email tomorrow morning, God willing. Regards Ahsan ========================================================== De: Michel Pons [technologyofficer@…] Envoyé: Thursday, September 03, 2009 8:32 AM À: 'Michael Halloran'; 'Ahsan Akhtar' Objet: RE: Status of work on COLTT Michael, Ahsan, I must admit I have some difficulties understanding the logic and reading the code. The only help I can provide is in making tests of any proposed modification. But for this I would need a build of the new COLTT. For the additional time, my impression is that SHMA can safely spend some additional hours. CO-LaN will pay for these according to the communication I saw from Ray Dickinson, CO-LaN’s president. Best regards Michel ======================================================= De: Michael Halloran [michaeljhalloran@…] Envoyé: Wednesday, September 02, 2009 10:26 PM À: Ahsan Akhtar Cc: Michel Pons Objet: Re: Status of work on COLTT Hi Ahsan, Thanks for committing the file. I have had a look and I still don't think the logic in COMQuery is right. I think that if m_pIPersistStream is undefined then the code must call QueryInterface, and if that call succeeds then it must store the returned pointer but also release it because the assignment to m_piPersistStream will cause an additional AddRef call - at least by my reading of the code for CCOMPtr in atlcomcli.h. If m_pIPersistStream is defined then the code should only return the logger interface appropriately addref'd. If m_IPersistStream is undefined and the call to QueryInterface fails then the code should return whatever the QI call returned for ppv. With the logic done this way, the release call that you commented out would only be called once and the assignment to m_pIPersistStream would only be called once no matter how many times COMQuery gets called for IPersistStream. I think that's correct. So this is what I think the code should look like: static HRESULT WINAPI COMQuery(void *pv, REFIID iid, LPVOID *ppv, DWORD dw) { ObjectLock lock(((CIPersistST*)pv)); HRESULT hr = S_OK; char MsgBuffer[256] = \"\"; if (iid == IID_IPersistStream) { if (!(((CIPersistST*)pv)->m_pIPersistStream)) { the QueryInterface call to the logged component sets ppv directly... hr = ((CIPersistST*)pv)->m_pUnkLoggedComponent->QueryInterface(IID_IPersistStream, ppv); if (SUCCEEDED(hr))
}
{
} else { This case will only happen if the QueryInterface call above failed... in this case ppv is equal to whatever the QueryInterface call to the logged component returned... ...which is what a failed QueryInterface call to a logger should return ((CIPersistST*)pv)->c_iid = IID_NULL; sprintf(MsgBuffer,\"%s : IPersistStream is not supported in the logged component\", ((CIPersistST*)pv)->m_sName.c_str()); } } else if (iid == IID_IPersistStreamInit) I think it's important to get this right because we could be introducing a reference counting issue, and the logic used for persistence interfaces is used again for error interfaces, so if persistence is wrong then so are errors. There's one thing I don't understand: in the original code, if m_pIPersistStream is defined when COMQuery is called then the code would assign the ppv passed into the call to m_pIPersistStream, which would overwrite the original ppv returned from QueryInterface in a previous call, then it would call release on that ppv. I think it should crash at this point because ppv is not going to be a valid IPersistStream interface pointer when the release call is made. To help me understand this, and to help decide whether the revised logic I've described above is correct, can you explain more about why commenting out the Release call fixed the problem? I think the effect of not releasing this pointer at all is that there will be an outstanding reference count on the logged component at the end of a run which will look like a memory leak. Commenting out the Release call also doesn't address the problem that if the first call to COMQuery correctly sets m_pIPersistStream, a second call will overwrite it with an invalid interface pointer. I'm aware that you are already over budget on the 150 hours block of work and I will try to reproduce the problem myself using coco, but I would appreciate any help you can provide and please record any time you spend on it so that we can reconcile it later. Note that I have not cc'd this to Anjum and Malcolm because it is very technical, but please feel free to forward it if necessary. Regards Michael ======================================================== De: Ahsan Akhtar [ahsan.akhtar@…] Envoyé: Tuesday, September 01, 2009 10:18 AM À: 'Michael Halloran'; anjum.raheel@… Cc: 'Woodman, Malcolm'; 'Michel Pons' Objet: RE: Status of work on COLTT Michael, I have uploaded the IPersistST.h file on sourceforge that I changed to fix the bug in case of goCO with AspenPlus. Regards Ahsan ============================================================ De: Michael Halloran [michaeljhalloran@…] Envoyé: Monday, August 31, 2009 6:28 PM À: Ahsan Akhtar; anjum.raheel@… Cc: Woodman, Malcolm; Michel Pons Objet: Re: Status of work on COLTT Hi Ahsan, Anjum, Thanks for your efforts over the last three months dealing with these issues. I have not seen any commits to SourceForge from SHMA since Ahsan's last commit on July 30th. I think there is at least one change outstanding - the fix for the problem with gCO in Aspen Plus - and maybe there are others as well. Even though you are already over the 150 hours allocation could I ask that you commit all outstanding changes to SourceForge so that we have access to the latest version of the source code? I have a large number of changes outstanding myself because I have changed the content of entries written to the log in order to make it easier to find real errors. I would like to commit these fixes but because so many files have changed I would rather do it after your commit so that I can merge the changes together. When Malcolm returns I'm sure we will find a resolution for the extra hours and for the small additional amount that I expect would be required to do the commit. Regards Michael ================================================== De: Michel Pons [technologyofficer@…] Envoyé: Tuesday, August 11, 2009 9:45 AM À: 'Ahsan Akhtar' Objet: RE: COLTT 09-015 Ahsan, I am not in my office on Wednesday and till Friday afternoon, leaving in fact late this afternoon for a business trip. How about next week? Best regards Michel ========================================================== De: Michel Pons [technologyofficer@…] Envoyé: Thursday, August 20, 2009 1:10 PM À: 'Michael Halloran' Cc: 'malcolm.woodman@…' Objet: COLTT 09-015 Michael, Ahsan has just finished a remote session on the CO-LaN laptop that apparently led to the resolution of the problem labeled 09-015 (gO:CAPE-OPEN in Aspen Plus). I was able to run the case with COLTT enabled on the gO:CAPE-OPEN UO. Ahsan told me that the issue was about reference counting. I can’t tell which lines of code were modified. Ahsan wants to discuss the issue with you. He thinks other parts of the code need to be modified as well. The modifications have not been committed to SourceForge. Best regards Michel =========================================================== De: Michel Pons [technologyofficer@…] Envoyé: Wednesday, August 19, 2009 12:12 PM À: 'Michael Halloran'; 'Ahsan Akhtar' Objet: RE: Debugging Issue Ahsan, Do you feel another remote session on the CO-LaN laptop is worth setting up this week, following the info supplied by Michael ? Best regards Michel =========================================================== De: Michael Halloran [michaeljhalloran@…] Envoyé: Wednesday, August 19, 2009 9:43 AM À: Ahsan Akhtar Cc: Michel Pons Objet: Re: Debugging Issue Ahsan, The simplest explanation is that the .pdb file you are using does not match the CoLoggersSt.dll that is being run in Aspen Plus. Can you check in the Visual Studio output window that when CoLoggersST.dll is loaded it is the DLL that you expect to be loaded i.e. it is in the right location, and that VIsual Studio reports that the debug symbols have been loaded. If both of those are correct then the problem is likely to be that the source code does not match the DLL and PDB files. Another way to force a break is to add the line _asm{int 3}; into the code where you want to start debugging. If that doesn't work you know that the DLL you expect to be loaded is not being loaded. Regards Michael ============================================================ De: Ahsan Akhtar [ahsan.akhtar@…] Envoyé: Wednesday, August 19, 2009 6:27 AM À: 'Michael Halloran' Cc: 'Michel Pons' Objet: Debugging Issue Michael, Yesterday , I had a PCNow session on COLaN laptop. During the session, I was able to run the case in Debug mode (i.e. I could attach the PME EXE with VS and could run the application in debug mode) but couldn't debug the case as VS didn't stop at debug break point. I used the same code that I use here at SHMA (which is also uploaded on SF). Please also note that and I can debug code at SHMA using COFE without any problem. Here is the sequence of steps that I performed to debug the case:
Best Regards Ahsan ===================================================== De: Michel Pons [technologyofficer@…] Envoyé: Tuesday, August 18, 2009 7:40 AM À: 'Michael Halloran' Cc: 'Ahsan Akhtar'; 'malcolm.woodman@…' Objet: RE: COLTT 09-015 Michael, I have now a virtual machine set up with Aspen Plus 7.1CP1, gPROMS 3.1.5, Visual Studio 2008 : Ahsan has positioned a remote debugging session this morning on the CO-LaN laptop for issue 09-015. Best regards Michel ======================================================= De: Michael Halloran [michaeljhalloran@…] Envoyé: Monday, August 17, 2009 11:27 PM À: Michel Pons Cc: Ahsan Akhtar; malcolm.woodman@… Objet: Re: COLTT 09-015 Michel, It seems to me that the problem is that with the 1.08.2 logger, the request to get the IPersistStorage interface fails and as a consequence the InitNew call is not made. I suspect the dialog that you don't see is invoked from InitNew rather than initialise. I can't tell from the code why the Query for IPersistStorage should fail, but this code has changed between 1.08.2 and 1.,07. I think Ahsan will need to debug this on your laptop to see what the PersistenceLogger is doing when asked for this interface. regards Michael ========================================================= De: Michel Pons [technologyofficer@…] Envoyé: Friday, August 14, 2009 5:14 PM À: 'Michael Halloran' Cc: 'Ahsan Akhtar'; 'malcolm.woodman@…' Objet: RE: gO:CAPE-OPEN in Aspen Plus Michael, I resent the logfile you asked for through yousendit.com since it may have been blocked by your firewall. With 1.08.02 enabled on the gO:CAPE-OPEN UO, there is no question asked by gO:CAPE-OPEN about a gCO file. I can’t proceed much further (Aspen Plus does not hang), since the UO is then not configured about ports and parameters so I can’t connect ports to it. Best regards Michel ======================================================= De: Michel PONS via YouSendIt [delivery@…] Envoyé: Friday, August 14, 2009 5:11 PM À: technologyofficer@… Objet: File Sent: apmain_081009_124510_v10802.log
========================================================= De: Ahsan Akhtar [sidathyder5@…] Envoyé: Friday, August 14, 2009 4:51 PM À: Michel Pons Objet: Re: COLTT 09-015 Michel, Yes, I will need VS to debug the case. Best Regards Ahsan ========================================================= De: Michel Pons [technologyofficer@…] Envoyé: Friday, August 14, 2009 4:38 PM À: 'Ahsan Akhtar' Objet: RE: COLTT 09-015 Ahsan, Tuesday August 18 is fine with me. In the meantime should I attempt to install Visual Studio 2008 in the VM dedicated to COLTT 09-015? Best regards Michel =========================================================== De: technologyofficer@… Envoyé: Wednesday, August 12, 2009 7:50 AM À: Michael Halloran Cc: Ahsan Akhtar; malcolm.woodman@… Objet: Re: gO:CAPE-OPEN in Aspen Plus Michael, I have not the log with me (being out of my office). But in both cases the Initialize is said to proceed well, i.e. no error. I do think that the dialog box comes indeed from the Initialize method. I will check also in the proprietary log file made by gO:CAPE-OPEN. I have to review how to configure it. Best regards Michel ============================================================ De: Michael Halloran [michaeljhalloran@…] Envoyé: Wednesday, August 12, 2009 12:07 AM À: Michel Pons Cc: Ahsan Akhtar; malcolm.woodman@… Objet: Re: gO:CAPE-OPEN in Aspen Plus Michel, Do you have a log for the 1.08.2 case? I think that gO:CAPE-OPEN displays the dialog in the Initialise call. I would like to know what the log says is happening then. Does Aspen Plus hang at the point when you expect to get the dialogue or does it continue as normal but with the GO;CAPE-OPEN Unit not configured correctly? Regards Michael ============================================================ De: Ahsan Akhtar [ahsan.akhtar@…] Envoyé: Wednesday, August 12, 2009 8:06 AM À: 'Michel Pons' Objet: RE: COLTT 09-015 Michel, Will it be fine to have this session on Tuesday at 8 am Paris in the next week? Best Regards Ahsan ================================================== De: Michel Pons [technologyofficer@…] Envoyé: Monday, August 10, 2009 12:54 PM À: 'Ahsan Akhtar'; 'Michael Halloran' Cc: 'malcolm.woodman@…' Objet: COLTT 09-015 Pièces jointes: apmain_081009_124051_v107.log; apmain_081009_124510_v10802.log Ahsan, Michael, To bring some light on the above referenced issue, I provide attached the logs obtained with v1.07 and v1.08.02. My understanding is that whatever goes wrong is within the Initialize method where my guess is that the request for a gCO file is made. It is clear from the logs that after leaving Initialize, the number of ports is zero in v1.08.02 and 2 in v1.07. Best regards Michel =================================================== De: Michel Pons [technologyofficer@…] Envoyé: Monday, August 10, 2009 11:26 AM À: 'Michael Halloran'; 'Ahsan Akhtar' Cc: 'malcolm.woodman@…' Objet: gO:CAPE-OPEN in Aspen Plus Hi, I am trying to document an issue about Aspen Plus that involves the use of a gO:CAPE-OPEN Unit Operation.
With COLTT 1.07 enabled on gO:CAPE-OPEN, I get a simulation which seems close to what happens without COLTT: the simulation goes to its end giving the same results. There is however a Microsoft Visual C++ Runtime Library error message box displayed when exiting Aspen Plus saying Runtime Error! Program: C: With COLTT 1.08.02 I do not get as far. I start, like with COLTT 1.07 from an Aspen Plus bkp file where the CAPE-OPEN UO is not showing. I need to instantiate the UO. When instantiating a gO:CAPE-OPEN UO in Aspen Plus (or other PME), there is a window popping up and asking about the location and name of a gCO file that is the configuration file for the gO:CAPE-OPEN Unit Operation. This happens when COLTT v1.07 is enabled on gO:CAPE-OPEN while this requests does not happen when COLTT 1.08.02 is enabled on gO:CAPE-OPEN. Hence I can’t get any further there. I have logged this issue as 09-015 and I have created a specific machine handling this case. It would be of interest to test COLTT 1.08.03 on this issue to figure out where we stand. Best regards Michel |
|||