Re: New Crash Related to Velocity Ruler

On 5/27/22 7:28 PM, Ted Felix wrote:
>    There's one more thing to check if core dumps still aren't being 
> created (/proc/sys/kernel/core_pattern).  See the wiki for details:
> 
> https://www.rosegardenmusic.com/wiki/dev:building_rosegarden_from_source#core_dumps 

There's something new to learn every day. :)


 > On 5/27/22 9:57 PM, Ted Felix wrote:
 >   I've had no trouble with them at all.  Just do a:
 >
 > gdb ./rosegarden ./core
 >
 >   Then "bt" for a backtrace.  Works like a charm every time for me. 
I > think gdb has improved immensely over the years.

Yes, of course (`gdb <executable-binary> <corefile>`). If there's a 
corefile, that is. ;)

Yes, GDB has grown by leaps and bounds, e.g. the Python 
replacement/addition to its original/native scripting language. That 
said, I've found it lags behind GCC's compiled C++. I've regularly 
crashed it (crashing the debugger, never a good sign) trying to step 
though Qt MOC code, to the point where I've given up trying. If I come 
across that again (by accident or on purpose) and you're interested I'll 
send the steps to reproduce.


> On 5/27/22 10:07 PM, Ted Felix wrote:
>    Ok, I found my notes on getting core dumps working everywhere:
>
> /etc/security/limits.conf is the right way to do this.  Add these lines:
>
> *               hard    core            unlimited
> *               soft    core            unlimited
>
> Reboot required.

No, I'd already checked that:

$ ulimit -c
unlimited


>    Now you should have a core dump on every crash.  Unless there is 
> already one present.  Then it will not write over it, unfortunately.

Let me try to return the favor. A little casual reading for pure 
enjoyment (more like self-inflicted torture) of `man core.5` led me to 
change from:

$ cat /proc/sys/kernel/core_pattern
|/bin/false

which was inhibiting corefiles by piping them to a null filter, to:

$ cat /proc/sys/kernel/core_pattern
core_%E_%p_%i_%s_%t

which not only enables corefiles but gives each one an overly-detailed 
unique name (including executable filename, process ID, and universal 
time) so new ones do *not* overwrite old/existing ones.


On 5/27/22 9:57 PM, Ted Felix wrote:
 >  The most irritating part is if I forget to delete the old one before 
 > I do a new run.  It won't write over the old one.  Definitely
 > been burned by that in the past.

Maybe try something like the above (could also be simplified) and see if 
you like it.




_______________________________________________
Rosegarden-user mailing list
[email protected] - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-user