Ah, I said: >(gdb)break std::bad_alloc::what()⏎ > > (it should NOT complain that this symbol isn't already loaded. If it > does, we might need to install the libststc++ debug symbols; haven't > used Ubuntu in a while, but probably `apt install libstdc++-dbg` or > `-dbgsym`
I was wrong, at that point it's totally OK to complain about missing symbol. Just say it's OK to set the breakpoint on future library load. On Tue, 2018-06-26 at 10:47 +0000, Müller, Marcus (CEL) wrote: > Hi Tom! > > Hm, no, I wouldn't be aware of any limitations, and even if such > exist, > things shouldn't die with a std::bad_alloc! > > Ok, so I'm wondering how we can move forward with this. Let us try > this: > > * Can you share a proof of failure flow graph with us? That way, > everyone's definitely talking about the same thing. > * I assume you've got GNU Radio built with debug symbols (cmake > -DCMAKE_BUILD_TYPE=RelWithDebInfo). This might even work if it > wasn't, > but the backtraces below might be less exciting. > * you'll need gdb > > gdb --args python2 /path/to/your/flowgraph.py⏎ > > (things flutter by) > > (gdb)start⏎ > > (things flutter by) > > (gdb)break std::bad_alloc::what()⏎ > > (it should NOT complain that this symbol isn't already loaded. If it > does, we might need to install the libststc++ debug symbols; haven't > used Ubuntu in a while, but probably `apt install libstdc++-dbg` or > `- > dbgsym`) > > (gdb)run⏎ > > (wait for the breakpoint defined above to trigger) > > (gdb)info threads⏎ > > (this is the list of currently existing threads. Copy and save.) > > (gdb)bt⏎ > > (short for `backtrace`. Now we should be getting a list that's > basically like "walking an onion from the middle to the peel", if > you're onion layers are defined by who called a function which called > a > function...) > > Share the output; if you look through it, the frame with the lowest > number that already happens somewhere inside libgnuradio-qtgui > probably > contains info on where exactly that allocation happens that fails. > > You can "jump" into that frame with `frame <number>`, replacing > <number> with the index given by #<number> in the backtrace. If these > variables/symbols weren't optimized away during compilation, you can > even use `print <variablename>` to print the values of local and > global > variables, or use `list` to print the source code of what you're > looking at (that definitely requires debug info to be included with > GNU > Radio's build). > > Best regards, > Marcus > > On Mon, 2018-06-25 at 16:52 -0700, Tom McDermott wrote: > > Ubuntu 16.04.3 > > GRC 3.7.11.1 (from git) > > I was on 3.7.13 couple of weeks ago, completely removed all of > > gnuradio > > and rebuilt trying to debug this. 3.7.11.1 had same problem. > > > > > > Got back to the problem of several weeks ago. > > > > 1. When I try to use a QT GUI sink (such as frequency) the > > invocation > > of > > the QT Gui Frequency sink in this example throws a memory > > allocation > > error. > > > > Qt has caught an exception thrown from an event handler. Throwing > > exceptions from an event handler is not supported in Qt. You must > > reimplement QApplication::notify() and catch all exceptions there. > > > > terminate called after throwing an instance of 'std::bad_alloc' > > what(): std::bad_alloc > > > > 2. If I remove the Row, Column GUI hints from just that one QT GUI > > item, then it > > comes up and runs OK. The other 9 of the QT controls (sliders, > > choosers, entry, > > ranges) still have their R,C hints. > > > > 3. Went back to the GRC file in step 1 that still has the R,C hints > > in it > > and it still fails with the error as shown in step 1. It did come > > up > > and run > > one time showing 'unable to set locale' error, but still > > ran. Never > > seen that before. > > > > > > Is there some limitation against using R,C hints on the QT displays > > (time, > > frequency, etc.)? > > > > -- Tom, N5EG > > > > > > > > > > _______________________________________________ > > Discuss-gnuradio mailing list > > Discuss-gnuradio@gnu.org > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
