Re: [Discuss-gnuradio] QT Gui mem alloc error - runs OK if R, C hints deleted

[CEL]

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
> > address@hidden
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

smime.p7s
Description: S/MIME cryptographic signature