I am using Quickfixj 2.3 for initiator. Vendor party is acceptor .
I have implemented SessionStateListener with the methods onConnectException and OnDisconnect.
I have resetOnLogon =Y in configuration file .
How can I catch specific exception like EndOfStream occurred ,due to wrong session data or due to acceptor allows only one session at a time or due to invalid Msg seq ?
Now, when the resetOnLogOn=Y,until the msgSeq satisfies, it keeps internally the disconnecting and initiating. I would like to logout manually in all other disconnects except this situation where it auto matches the seq number .
Thank you .
You actually cannot tell the scenarios listed in point 1 apart most of the time.
E.g. the counterparty normally will not tell you if you have wrong session data (I assume you mean wrong SenderCompID or TargetCompID) because that would disclose information about their system. Same goes for the duplicate session.
Only in the case of a "sequence number too low" event the counterparty normally will send this information in the 58/Text field of the Logout message.
I am a graduate student (master's) and use an in-house code for running my simulations that use MPI. Earlier, I used OpenMPI on a supercomputer we used to access and since it shut down I've been trying to switch to another supercomputer that has Intel MPI installed on it. The problem is, the same code that was working perfectly fine earlier now gives memory leaks after a set number of iterations (time steps). Since the code is relatively large and my knowledge of MPI is very basic, it is proving very difficult to debug it.
So I installed OpenMPI onto this new supercomputer I am using, but it gives the following error message upon execution and then terminates:
Invalid number of PE
Please check partitioning pattern or number of PE
NOTE: The error message is repeated for as many numbers of nodes I used to run the case (here, 8). Compiled using mpif90 with -fopenmp for thread parallelisation.
There is in fact no guarantee that running it on OpenMPI won't give the memory leak, but it is worth a shot I feel, as it was running perfectly fine earlier.
PS: On Intel MPI, this is the error I got (compiled with mpiifort with -qopenmp)
Abort(941211497) on node 16 (rank 16 in comm 0): Fatal error in PMPI_Isend: >Unknown error class, error stack:
PMPI_Isend(152)...........: MPI_Isend(buf=0x2aba1cbc8060, count=4900, dtype=0x4c000829, dest=20, tag=0, MPI_COMM_WORLD, request=0x7ffec8586e5c) failed
MPID_Isend(662)...........:
MPID_isend_unsafe(282)....:
MPIDI_OFI_send_normal(305): failure occurred while allocating memory for a request object
Abort(203013993) on node 17 (rank 17 in comm 0): Fatal error in PMPI_Isend: >Unknown error class, error stack:
PMPI_Isend(152)...........: MPI_Isend(buf=0x2b38c479c060, count=4900, dtype=0x4c000829, dest=21, tag=0, MPI_COMM_WORLD, request=0x7fffc20097dc) failed
MPID_Isend(662)...........:
MPID_isend_unsafe(282)....:
MPIDI_OFI_send_normal(305): failure occurred while allocating memory for a request object
[mpiexec#cx0321.obcx] HYD_sock_write (../../../../../src/pm/i_hydra/libhydra/sock/hydra_sock_intel.c:357): write error (Bad file descriptor)
[mpiexec#cx0321.obcx] cmd_bcast_root (../../../../../src/pm/i_hydra/mpiexec/mpiexec.c:164): error sending cmd 15 to proxy
[mpiexec#cx0321.obcx] send_abort_rank_downstream (../../../../../src/pm/i_hydra/mpiexec/intel/i_mpiexec.c:557): unable to send response downstream
[mpiexec#cx0321.obcx] control_cb (../../../../../src/pm/i_hydra/mpiexec/mpiexec.c:1576): unable to send abort rank to downstreams
[mpiexec#cx0321.obcx] HYDI_dmx_poll_wait_for_event (../../../../../src/pm/i_hydra/libhydra/demux/hydra_demux_poll.c:79): callback returned error status
[mpiexec#cx0321.obcx] main (../../../../../src/pm/i_hydra/mpiexec/mpiexec.c:1962): error waiting for event"
I will be happy to provide the code in case somebody is willing to take a look at it. It is written using Fortran with some of the functions written in C. My research progress has been completely halted due to this problem and nobody at my lab has enough experience with MPI to resolve this.
I have a Kuka arm and some objects set up in my simulation(very similar to manipulation station example), and I have been running into coredump error below whenever there is a contact between the robot and the objects.
"abort: Failure at multibody/plant/multibody_plant.cc:1640 in CalcImplicitStribeckResults(): condition 'info == ImplicitStribeckSolverResult::kSuccess' failed.
Aborted (core dumped)"
Decreasing the integration step size for the simulator did not help, so I ended up tracing back the error and commented out the condition that is causing the error( "DRAKE_DEMAND(info == ImplicitStribeckSolverResult::kSuccess);" ), which seems to coredump a lot less often.
However, I am guessing that condition is there for a reason, so would commenting the line out cause any other issues in the simulation? What is the proper way to fix the coredump problem?
In Drake PR #12503, the ImplicitStribeck code was refactored to reflect the notation in the TAMSI arXiv paper, and in #12361 it was changed to provide a more helpful exception with troubleshooting tips:
https://github.com/RobotLocomotion/drake/blob/v0.15.0/multibody/plant/multibody_plant.cc#L1866-L1878
Can you try out a later version (e.g. 0.15.0), and then try out the troubleshooting instructions there? (You've already tried changing step size in the simulator, but you may want to check on the stiffness of your overall system, etc.)
while running my iOS app i get the message:
2017-11-04 15:33:02.873595+0100 DagBoek[71486:4321269] ***
-[NSKeyedUnarchiver initForReadingWithData:]: data is NULL
in the XCODE console
DagBoek[71486:4321269] What do the numbers between the brackets mean ?
Can they help me to find where in my code the problem is ?
Thanks
No, they don't really help much. The first number, 71486 in your example, is the process ID (PID). The second number (4321269) is a thread ID of sorts, but Apple's diagnostic and debugging tools seem to use different thread ID schemes in different contexts, so it's mostly useless.
I am using C++ Builder XE7 VCL.
Around August 11 2016 2:00pm UTC, I started receiving multiple complaints from my user base about printing problems. Most of these printing modules have proven stable for many years, and there were no updates to my project within the past 24 hours. I was able to reproduce similar problems on my development/test environment.
Without going into many details of my project, let me present a very simple printing program that is failing:
void __fastcall TForm1::PrintButtonClick(TObject *Sender)
{
// Test Print:
TPrinter *Prntr = Printer();
Prntr->Title = "Test_";
Prntr->BeginDoc();
Prntr->Canvas->Font->Size = 10;
Prntr->Canvas->TextOut(300,1050,"* * * Printing Test * * *");
if (Prntr->Printing) {
Prntr->EndDoc();
}
}
On the first attempt to print, everything works perfectly as expected. If I click the button a second time, TPrinter produces a small PDF, but the PDF file is actually corrupted and appears to have a file handle stuck to it.
If I click the button a third time, I get no printing and the following error message appears:
Printer is not currently printing.
My own test was done using a PDF printer driver, but the complaints I am receiving from users include a variety of local printers, network printers, PDF printers, etc.
In my actual project, I have try/catch exception handling, so the actual results are slightly different, but substantially similar to this result. The results show the hallmarks of instability and/or memory leaks without much in terms of error messages.
I suspect there may have been some Microsoft Windows updates that are tangling with Embarcadero DLLs, but I have not been able to verify this so far.
Is anyone else having similar problems?
The reason using a TPrintDialog or TPrinterSetupDialog "works" to fix the error is because they force the singleton TPrinter object (returned by the Vcl.Printers.Printer() function) to release its current handle to a printer if it has one, thus causing TPrinter.BeginDoc() to create a new handle. TPrinter releases its printer handle when:
it is being destroyed.
its NumCopies, Orientation, or PrinterIndex property is set.
its SetPrinter() method is called (internally by the PrinterIndex property setter and SetToDefaultPrinter() method, and by TPrintDialog and TPrinterSetupDialog).
Without doing that, calling TPrinter.BeginDoc() multiple times will just keep re-using the same printer handle. And apparently something about the recent Microsoft security update has now affected that handle reuse.
So, in short, (without uninstalling the Microsoft update) in between calls to BeginDoc() you need to do something that causes TPrinter to release and recreate its printer handle, and then the problem should go away. At least until Embarcadero can release a patch to TPrinter to address this issue. Maybe they could update TPrinter.EndDoc() or TPrinter.Refresh() to release the current printer handle (they currently do not).
Therefore, the following workaround resolves the printing issue without requiring any changes to the user interface:
void __fastcall TForm1::PrintButtonClick(TObject *Sender)
{
// Test Print:
TPrinter *Prntr = Printer();
Prntr->Title = "Test_";
Prntr->Copies = 1; // Here is the workaround
Prntr->BeginDoc();
if (Prntr->Printing) {
Prntr->Canvas->Font->Size = 10;
Prntr->Canvas->TextOut(300,1050,"* * * Printing Test * * *");
Prntr->EndDoc();
}
}
There are no Embarcadero DLLs involved in printing. TPrinter simply calls Win32 API GDI-based print functions directly.
The "Printer is not currently printing" error occurs when one of the following operations is performed on a TPrinter when its Printing property is false:
TPrinter::NewPage()
TPrinter::EndDoc()
TPrinter::Abort()
a TPrinter::Canvas subproperty is being changed.
the TPrinter::Canvas is being drawn on.
You are performing half of these operations in the test code you have shown, but you did not specify which line of code is actually throwing the error.
The Printing property simply returns the current value of the TPrinter::FPrinting data member, which is set to false only when:
the TPrinter object is initially created (the Printer() function returns a singleton object that is reused for the lifetime of the executable).
the Win32 API StartDoc() function fails inside of TPrinter::BeginDoc() (FPrinting is set to true before StartDoc() is called).
TPrinter::EndDoc() is called when Printing is true.
So, given the test code you have shown, there are two possibilities:
StartDoc() fails and you are not checking for that condition. BeginDoc() will not throw an error (VCL bug?!?), it will simply exit normally but Printing will be false. Add a check for that:
Prntr->BeginDoc();
if (Prntr->Printing) { // <-- here
Prntr->Canvas->Font->Size = 10;
Prntr->Canvas->TextOut(300,1050,"* * * Printing Test * * *");
Prntr->EndDoc();
}
the Printing property is getting set to false prematurely while you are in the process of printing something. The only ways that could happen in the code shown are if:
random memory is being corrupted, and TPrinter happens to be the victim.
multiple threads are manipulating the same TPrinter object at the same time. TPrinter is not thread-safe.
Since you can reproduce the problem in your development system, I suggest you enable Debug DCUs in the project options, then run your app in the debugger, and put a data breakpoint on the TPrinter::FPrinting data member. The breakpoint will be hit when FPrinting changes value, and you will be able to look at the call stack to see exactly which code is making that change.
Based on this information, I am going to go out on a limb and guess that the cause of your error is StartDoc() failing. Unfortunately, StartDoc() is not documented as returning why it fails. You certainly cannot use GetLastError() for that (most GDI errors are not reported by GetLastError()). You might be able to use the Win32 API Escape() or ExtEscape() function to retrieve an error code from the print driver itself (use TPrinter::Canvas::Handle as the HDC to query). But if that does not work, you won't be able to determine the reason of the failure, unless Windows is reporting an error message in its Event Log.
If StartDoc() really is failing, it is because of an Win32 API failure, not a VCL failure. Most likely the printer driver itself is failing internally (especially if a PDF print driver is leaving an open file handle to its PDF file), or Windows is failing to communicate with the driver correctly. Either way, it is outside of the VCL. This is consistent with the fact that the error started happening without you making any changes to your app. A Windows Update likely caused a breaking change in the print driver.
Try removing the following Windows update:
Security Update for Microsoft Windows (KB3177725)
MS16-098: Description of the security update for Windows kernel-mode drivers: August 9, 2016
This appears to resolve the issue for several test cases so far.
It started happening here today too. On my Windows 10 setup this would happen after calling TForm's Print() 3 times. I tried both the Microsoft Print to PDF and the Microsoft XPS Document Writer and both gave the same error.
I did some quick debugging and found that it's the call to StartDoc() that returns a value <= 0.
A temp fix until I can figure out what is really causing this is to re-create the Printer object in Printers by calling
Vcl.Printers.SetPrinter(TPrinter.Create).Free;
after calling anything that is using the Printer object. Might not be advisable to do that, but it solved my issue for now.
Looks like something is not released properly when calling EndDoc()
It seems that this is really a Microsoft problem and they should fix this buggy update. You can find more info at this on the company site.
Using a Printer Setup Dialog is only a workaround, not real solution, for this Microsoft bug. After confirmation, the printer setup dialog always creates a new handle for the printer. The next one or two print jobs will then succeed.
The patch should come from Microsoft, not from Embracadero. Thousands of programs are affected and it would be a massive waste of time and money to implement a workaround in all of them, if there is a bug in MS update.
I started experiencing the same weird behavior at more or less the same time, when running 32 bit Delphi applications built in XE7 on a Windows 10 64 bit system.
After uninstalling the latest security upgrade for Windows 10 (KB3176493), printing from these applications works normally again.
A rather surprising side effect of uninstalling this update seems to be that the file associations - which are the default programs for handling specific file types - are being reverted to Microsoft Windows default values...
The following variation of the code in the question will resolve the problem, but requires a TPrinterSetupDialog component added to the form:
void __fastcall TForm1::PrintButtonClick(TObject *Sender)
{
// Test Print:
TPrinter *Prntr = Printer();
Prntr->Title = "Test_";
PrinterSetupDialog1->Execute();
Prntr->BeginDoc();
if (Prntr->Printing) {
Prntr->Canvas->Font->Size = 10;
Prntr->Canvas->TextOut(300,1050,"* * * Printing Test * * *");
Prntr->EndDoc();
}
}
For program usage, the user will be presented with the printer setup dialog before proceeding to printing.
As to "why", my best guess at this point is that TPrinter used alone does not have all necessary permissions to access all necessary resources from Windows after the Security Update for Microsoft Windows (KB3177725) was implemented on Aug 10, 2016. Somehow a call to TPrinterSetupDialog (or TPrintDialog) before calling BeginDoc() sets up the necessary conditions for TPrinter to perform successfully.