Related
I am starting a C++ project in which I wish to use elements from both the Qt environment and boost libraries. Also, Google Test will be the unit testing framework.
It is the very beginning of the project and therefore it contains a tiny amount of code (a few member accessor functions for one class).
Yet, as soon as I started to compile with boost (boost_filesystem), I got a core dumped in the middle of the tests run by Google Test. These tests were running fine before. The core dump occurs long before I am calling any boost function. Also, even if I comment out the code that call boost functions and just link with boost, I still get the core dump in the same place.
This core dump occurs in the middle of a list of EXPECT_DEATH calls that I use to test that my Q_ASSERT assertions do indeed get triggered on invalid inputs. I know that EXPECT_DEATH is costly but so far it worked fine (before I linked to Boost). In my current test scenario, I must be calling it a little under 100 times. Here is an example:
l_item.setFlags(CorpusStore::FULL_EDGE);
EXPECT_DEATH(l_item.text(), "");
EXPECT_DEATH(l_item.setText("toto"), "");
The code that will trigger the death is:
void CorpusStore::Item::setText(const QString& p_text){
qCDebug(g_cat_store) << QString("setting text to [%1] (len = %2)").arg(p_text).arg(p_text.length());
Q_ASSERT_X((m_flags & (ITEM_IS_VERTEX | ITEM_IS_SIMPLE)) != 0, "Item::setText()", "cannot be a full edge");
Q_ASSERT_X(((m_flags & (ITEM_IS_VERTEX | ITEM_IS_SIMPLE)) == ITEM_IS_SIMPLE) ? (p_text.length() < SIMPLE_EDGE_TEXT_LEN) : true,
"Item::setText()", "simple edge --> length must be < SIMPLE_EDGE_TEXT_LEN");
Q_ASSERT_X(((m_flags & (ITEM_IS_VERTEX | ITEM_IS_SIMPLE)) == (ITEM_IS_VERTEX | ITEM_IS_SIMPLE)) ?
(p_text.length() < SIMPLE_VERTEX_TEXT_LEN) : true,
"Item::setText()", "simple vertex --> length must be < SIMPLE_VERTEX_TEXT_LEN");
Like I said, I have a little under 100 tests that look like this (plus a number of EXPECT_EQ, etc)
I know that people are going to tell me that I should not use so many EXPECT_DEATH to test asserts and that I should use Google Test's own assert macros instead of Qt's. Okay, Okay, but ...
This is what I want to do ...
The core dump should not happen even if I use a million EXPECT_DEATH.
There is obviously a bug somewhere and so it is worth investigating (hint, hint, Boost, Qt and Google Test people)
Here is my main function:
int main(int argc, char *argv[])
{
::testing::InitGoogleTest(&argc, argv);
CorpusStore::CorpusEnv::init();
//CorpusStore::Storage::init();
return RUN_ALL_TESTS();
}
The commented out line in the middle is where the Boost functions would be called. As I said, I get a core dumped nonetheless. CorpusStore::CorpusEnv::init() is my own initialization code that I need to call before the tests begin.
I am using the Qt build system, which may not be familiar to many. In essence it generates a Makefile, just like CMake does. In addition to the Qt libraries, I am just linking with two more: libgtest.a and libboost_filesystem.a
HELP!!....
------------ EDITS ------------
Based on #Some programmer dude comments below.
On the debugger, I am just seeing that the core dump happens in the middle of a malloc call and I can see some disassembled code. But the context (what call caused it) is not clear. Some of the code just before the malloc call contains what appears to be Qt Symbols. The function call stack starts inside the libc-start.c library which, I guess, must be called after a fork call due to the EXPECT_DEATH. What is weird is that this stretch of code worked ok before I started linking with libboost_filesystem.a and no code from that library does appear in the debugger function call stack. If I remove all the boost related code and stop linking to it, my whole test suit works.
This is the situation where it happens (messages from qDebug()):
...
[Debug] 17:14:32.209 (void CorpusStore::Item::setFlags(CorpusStore::FlagField) ../Corpus/corpus_store.cpp:338) "Setting flags to 0x3 (0b0000000000000000000000000000000000000000000000000000000000000011)"
[Debug] 17:14:32.209 (void CorpusStore::Item::setReciprocal(CorpusStore::ItemID) ../Corpus/corpus_store.cpp:498) "setting reciprocal edge to 2416"
[Fatal] 17:14:32.209 ( ../Corpus/corpus_store.cpp:499) ASSERT failure in Item::setReciprocal(): "accessing the reciprocal of an item that is not a full edge", file ../Corpus/corpus_store.cpp, line 499
[Debug] 17:14:32.309 (CorpusStore::ItemID CorpusStore::Item::reciprocal() ../Corpus/corpus_store.cpp:506) "Getting reciprocal edge ..."
[Fatal] 17:14:32.309 ( ../Corpus/corpus_store.cpp:507) ASSERT failure in Item::reciprocal(): "accessing the reciprocal of an item that is not a full edge", file ../Corpus/corpus_store.cpp, line 507
[Debug] 17:14:32.408 (void CorpusStore::Item::setFlags(CorpusStore::FlagField) ../Corpus/corpus_store.cpp:338) "Setting flags to 0x2 (0b0000000000000000000000000000000000000000000000000000000000000010)"
[Debug] 17:14:32.408 (void CorpusStore::Item::setReciprocal(CorpusStore::ItemID) ../Corpus/corpus_store.cpp:498) "setting reciprocal edge to 2417"
[Fatal] 17:14:32.408 ( ../Corpus/corpus_store.cpp:499) ASSERT failure in Item::setReciprocal(): "accessing the reciprocal of an item that is not a full edge", file ../Corpus/corpus_store.cpp, line 499
[Debug] 17:14:32.507 (CorpusStore::ItemID CorpusStore::Item::reciprocal() ../Corpus/corpus_store.cpp:506) "Getting reciprocal edge ..."
[Fatal] 17:14:32.507 ( ../Corpus/corpus_store.cpp:507) ASSERT failure in Item::reciprocal(): "accessing the reciprocal of an item that is not a full edge", file ../Corpus/corpus_store.cpp, line 507
[Debug] 17:14:32.606 (void CorpusStore::Item::setFlags(CorpusStore::FlagField) ../Corpus/corpus_store.cpp:338) "Setting flags to 0x2 (0b0000000000000000000000000000000000000000000000000000000000000010)"
[Debug] 17:14:32.607 (void CorpusStore::Item::setFirstEdge(CorpusStore::ItemID) ../Corpus/corpus_store.cpp:518) "setting first edge to 2327"
[Fatal] 17:14:32.607 ( ../Corpus/corpus_store.cpp:519) ASSERT failure in Item::setFirstEdge(): "accessing the first edge on a non-full item", file ../Corpus/corpus_store.cpp, line 519
Segmentation fault (core dumped)
Each of the [Fatal] messages above corresponds to an EXPECT_DEATH test that has succeeded because a Q_ASSERT has been triggered (see code above). Normally, this output would continue for about 50 more lines, corresponding to more tests. Now it is interrupted in the middle. The point at which it stops doe not seem special in any way. But it stops always at the same point. It is not random.
When the crash happens, I do not see any of my variables (or my function calls) in the debugger, which is why I think it must take place during a fork call before my code gets activated. A problem related to the loading of a library could happen at that point I guess?
This is what I see in the debugger window:
None of it seems particularly helpful.
Found the solution!
Thanks to #sehe and #Genjutsu's comments above.
I recompiled libboost_filesystem.a from sources and it works now.
So the takeaway is: Don't trust Ubuntu/Debian's binary packages. For Boost, at least, they are not guaranteed to work. Why? I have no idea ...
So I am building a redhawk module and trying to just pass data through it as a test. After putting their example of how to work with input and output ports into the serviceFunction() I am able to build the module with no errors (I changed variable names to match my ports). When I put the module on the white board and link it up it's fine but as soon as I start the module it crashes. I added a line to write the incoming stream id to the console and that will hit the console 10 to 20 times before the crash (it correctly writes the id of the signal generator that is providing the signal). If I plot the output port nothing is plotted before the crash (when I say crash I mean that the module just disappears from the white board, the ide is still up and running).
The service function is:
int freqModFrTest_i::serviceFunction()
{
bulkio::InFloatPort::dataTransfer *tmp = dataFloatIn->getPacket(bulkio::Const::BLOCKING);
if (not tmp) { // No data is available
return NOOP;
}
else
{
std::cout<<tmp->streamID<<std::endl;
std::vector<float> outputData;
outputData.resize(tmp->dataBuffer.size());
for (unsigned int i=0; i<tmp->dataBuffer.size(); i++) {
outputData[i] = (float)tmp->dataBuffer[i];
}
// NOTE: You must make at least one valid pushSRI call
if (tmp->sriChanged) {
ComplexOut->pushSRI(tmp->SRI);
}
ComplexOut->pushPacket(outputData, tmp->T, tmp->EOS, tmp->streamID);
delete tmp; // IMPORTANT: MUST RELEASE THE RECEIVED DATA BLOCK
return NORMAL;
}
}
Has anyone had a similar issue or any ideas on what would be causing this?
Additional Info:
Following the sugestion by pwolfram I built a sig generator and this component into a waveform. When launching it from a domain I got the error:
2016-01-14 07:41:50,430 ERROR DCE:aa1a189e-0b5b-4968-9150-5fc3d501dadc{1}:1030 -
Child process 3772 terminated with signal 11
when trying to restart the component (as it just stoped rather then disapering) I get the following error:
Error while executing callable. Caused by org.omg.CORBA.TRANSIENT:
Retries exceeded, couldn't reconnect to 10.62.7.21:56857
Retries exceeded, couldn't reconnect to 10.62.7.21:56857
In REDHAWK 2.0.0 I created a component with the same name (freqModFrTest) and port names (dataFloatIn and ComplexOut) and used your service function verbatim. I did not however get any issues.
Here are a few things to try:
Clean and rebuild the component. The Sandbox (what you referred to as the whiteboard) will run the binary that has been built. It is possible that you've modified the code and have an older version of the binary on disk. Right click on the project and select "clean project". Then right click and select "Build Project" this will make sure that the binary matches your source code.
Run the component in debug mode. If you double click on the SPD file, under the "overview" tab there is "Debug a component in the sandbox". This will launch the component in the chalkboard within a debugging context. You can set breakpoints and walk through the code line by line. If you set no breakpoints though the IDE will stop execution when a fatal error occurs. If there is an issue (like invalid memory access) the IDE will prompt you to enter debug mode and it should point out the line in code where the issue is.
If those options fail, you can enable core dumps and use GDB to see where in the code the issue is occurring. There are lots of tutorials online for GDB but the gist is that before launching the IDE, you'll want to type "ulimit -c unlimited" then from the same terminal, launch the IDE. Now when your component dies, it will produce a core file.
Hopefully one of these gets you going down the right path.
First some introducing.
I am trying to make the MFRC522 library for Arduino work on an ATmega328 programmed in C(I am using a 'normal' controller first, to make it work on a raspberry pi in a later state).
I copied the .h and .cpp from the library to my own project and renamed the .c to .cpp. After removing the classes in the .h file, it was time for the .c file. I replaced all the 'byte' statements to 'uint8_t', replaced the 'Serial.print' with printf and did the changes for GPIO and SPI.
The problem.
After some small mistakes I finally got data from a keycard. However it looked like to work, I get an error with reading line 58 from the card. The error is:
MIFARE_READ() failed: A MIFARE PICC responded with NAK.
I added a print statement to the SPI write and read and found out the following difference(on the left the [C] version and on the right the Arduino version): (because of my reputation, the picture can be found in the BitBucket I mentioned at the code part)
Code
The code is pretty long, but i made it available on BitBucket
I hope someone can point me where to look(some [C++] >> [C] different interpretations), because I don't know anymore where to look.
Sander
You need to run the PCD_Authenticate function before reads and writes. There are a few pre programmed keys in the linked github library that will authenticate the cards. I was getting this when trying to write to the card because I was using KEY_B and not KEY_A. You can see this Authenticate used in the samples provided on that GitHub page. It should looks something like this.
status = (MFRC522::StatusCode) mfrc522.PCD_Authenticate(MFRC522::PICC_CMD_MF_AUTH_KEY_A, trailerBlock, &key, &(mfrc522.uid));
From what I can tell the NAK simply means that the wrong key was used or maybe no key.
I am an MPI and Fortran 77 noob. I have a fortran 77 code FKRPRO.f which I wanted to parallelize using OpenMPI. The code requires a lot of parameters which are fed into it during run time from a separate file. Compilation and running is something like this
gfortran -o FKRPRO FKRPRO.f
./FKRPRO < Modelfile.txt
the equivalent lines in the code (not my code) are
PARAMETER(LIN=5)
INTEGER ERROR
LOGICAL PRNTA
PRNTA=.FALSE.
READ(LIN,'(L3)') PRNTA
READ(LIN,21) M1,M2
21 FORMAT(11I5)
and so on. Can someone please explain to me what READ(LIN,'(L3)') PRNTA means. The input in the input file Modelfile.txt is something like this
.F.
0 64
and so on..
I put the necessary MPI statements in the code.
INCLUDE 'MPIF.H'
...
CALL MPI_INIT(ERROR)
CALL MPI_COMM_SIZE(MPI_COMM_WORLD,NPROCS,ERROR)
CALL MPI_COMM_RANK(MPI_COMM_WORLD,PRANK,ERROR)
...
CALL MPI_TYPE_FREE(NEWMATRIX,ERROR)
CALL MPI_FINALIZE(ERROR)
All processes are not being able to read the input file. I have compiled and run the code like this
mpif77 -o bc3 FKRPROG5.f
mpirun -np 4 bc3 < Modelfile.txt
This is not working. I get the following errors. Only the first process or rank 0 can read the file.
At line 50 of file FKRPROG5.f (unit = 5, file = 'stdin')
Fortran runtime error: End of file
At line 50 of file FKRPROG5.f (unit = 5, file = 'stdin')
Fortran runtime error: End of file
At line 50 of file FKRPROG5.f (unit = 5, file = 'stdin')
Fortran runtime error: End of file
mpirun has exited due to process rank 3 with PID 866 on
node Avinash-rMBP.local exiting improperly. There are two reasons this could occur:
1. this process did not call "init" before exiting, but others in
the job did. This can cause a job to hang indefinitely while it waits
for all processes to call "init". By rule, if one process calls "init",
then ALL processes must call "init" prior to termination.
2. this process called "init", but exited without calling "finalize".
By rule, all processes that call "init" MUST call "finalize" prior to
exiting or it will be considered an "abnormal termination"
This may have caused other processes in the application to be
terminated by signals sent by mpirun (as reported here).
50th line is READ(LIN,'(L3)') PRNTA.Someone kindly point out where I am going wrong :(
So, how can I make all processes read from this input file < Modelfile.txt ?? Thanks.
The statement
READ(LIN,'(L3)') PRNTA
causes the program to read, from the unit attached to the channel with id LIN, a 3-character sequence which represents a logical value and assigns the value read to the variable PRNTA. From the fragments you've shown us the program will read .F. and set PRNTA to .false..
LIN is set to the constant value 5, which usually means stdin. This use of 5 to denote stdin is not a de jure standard, it is more of a de facto standard.
The straightforward way to read a parameter file into an MPI program is to ensure that only one process reads the file and then sends out the values to the other processes which need them.
You seem to have written a program in which all processes try to read the same input file but, at run-time, the redirection you've used to pass Modelfile.txt is only working for one process (presumably the process with rank 0). The other processes are not getting an input file at all and are complaining, then bringing the program crashing down. The error message you show is typical of a Fortran program which doesn't find an input file at all when it tries to read.
Far better to write code along the lines:
call mpi_init ...
...
if (myrank==0) then
open(...) inputfile
read(...) parameters
close(...)
end if
...
call mpi_bcast(parameters from 0 to all)
...
In general, don't expect the run-time environment for MPI processes to be identical copies of the run-time environment for a sequential program. I think that you are seeing evidence that your run-time directs the input only to the first process created when your program runs. Since mpirun is not standardised (though mpiexec is) I don't think you can rely on this run-time behaviour being the same for all MPI implementations. For portability and compatibility you're better off handling I/O explicitly within your program than using o/s features such as redirection.
You could, rather than have process 0 read the parameters and distribute them to other processes, write your code such that each process reads the same file. If you do write your code this way take care to ensure that the processes aren't fighting over access to the I/O channels; having multiple processes trying to (nearly-)simultaneously read across a single input channel is a sure way to slow things down.
I've got a protected object that presents functions and procedures in its interface.
In gdb, when I set a bp on the first line of one of those, I get odd results.
Here's a snippet from my gdb console:
(gdb)
(gdb) b database-access_manager.adb:20001
Breakpoint 3 at 0x1a10588: file y:/svs/central_switch/controller/database/
database-access_manager.ads, line 20001.
(gdb)
You can see that gdb is confused. I specified a bp at 20001 of the .adb file but gdb responded by saying it had set the bp at 20001 of the corresponding ads file - which doesn't have that many lines.
What gives?
That .ads file wouldn't happen to be defining or using a generic, would it?
I have yet to find a debugger that handles Ada generics very well. The compiler often creates a raft of semi-invisible code that confuses the heck out of debuggers. I suspect C++ templates have the same issue.
Another possibility is that you are looking at a source file that has been modified since your program was compiled.
Running on Windows with GNAT Pro 6.3.1 (I realise this isn't an ideal data point for you!) this worked fine.
I did notice that when I requested a bp on the subprogram specification, GDB effectively set two bps, one in the specification and one at the first statement: so, given
package body Protected_Object is
protected body PO is
procedure Put (V : Integer) is
begin
Value := V;
end Put;
function Get return Integer is
begin
return Value;
end Get;
end PO;
end Protected_Object;
the GDB console says (for Put)
gdb) break protected_object.adb:4
Breakpoint 1 at 0x401729: file protected_object.adb, line 6. (2 locations)
and at run time, sure enough there are 2 breaks:
Breakpoint 1, <protected_object__po__putP> (<_object>=..., v=42) at protected_object.adb:4
(gdb) cont
Breakpoint 1, protected_object.po.put (<_object>=..., v=42) at protected_object.adb:6
Version: GNU gdb (GDB) 7.0.1 for GNAT Pro 6.3.1 (20100112) [rev:158983]
Here's the update on my problem.
I made a protected type with access methods and used it in a small main and found that breakpoints in my example protected type worked fine.
Now I'm trying to understand why, within the context of my company's very large build, the breakpoints don't work.
I'm using the same gdb, GPS, & compiler switches in each case and it works for the small program but not in the large one.
I'll post my results when/if I have any.
Thanks to all the repliers.
Tom