[L2Ork-dev] Purr Data 2.4.4

[Albert Graef]

On Mon, Dec 11, 2017 at 10:28 PM, Alberto Zin <alberto.zin at gmail.com> wrote:

> for some reasons I'm not yet able to investigate in detail, this release
> 2.4.4 of purr-data broke something on my system.
> Many of my past patches, when opened present a "segmentation fault" error.
>

This sounds like a rogue external to me. To check this, reset the
preferences (after backing them up), as explained here:
https://agraef.github.io/purr-data-intro/Purr-Data-Intro.html#resetting-the-preferences

If Purr then runs normally, it must be one of the externals you added. You
may then start re-adding your local externals one by one until Purr crashes
again, at which point you will have identified the culprit, and can report
the problem on the bug tracker of the corresponding project.

Otherwise, it may be a bug in Purr, or, equally likely, a misbehaving
build. Since you're running my packages, you can check whether you can
reproduce the problem with Jonathan's package (as you're running Trusty,
that would be
https://github.com/agraef/purr-data/releases/download/2.4.5/pd-l2ork-2.4.5-ubuntu_14.04-x86_64.zip).
These are produced in different ways on different systems, so a packaging
bug might show up up in one but not the other.

If only one of the alternative packages exhibits the problem then it's
clearly a packaging bug which you should report to the package maintainer
(that would be me if only the JGU package appears to be borked; I have a
bug tracker for packaging bugs concerning the JGU packages here:
https://bitbucket.org/l2orkubuntu/l2orkubuntu.bitbucket.org/issues).

If neither of the packages work for you, then you might have hit a bug in
Purr, or a platform-specific issue which should be reported at
https://git.purrdata.net/jwilkes/purr-data/issues

My simple question is; in order to debug the issue and report something
> useful to the issue tracker on github
> do I need to build a purr-data version myself with the debug flags
> enabled?
>

That would be a lot of hassle. The first thing I'd try is to boil the issue
down to a Pd patch as simple as possible and attach that to your problem
report. Your bug report should describe the problem and the exact steps
needed to reproduce it. A log of what you see in the terminal when you
launch Purr from the command line may also be helpful. Then someone from
your friendly developer team will hopefully be able to figure it out. ;-)
If we can't reproduce the problem then we'll get back to you and ask for
more information.

There are also ways you can run Purr inside gdb (using the "Purr Data
DEBUG" icon), which will hopefully give you a backtrace (use gdb's bt
command after Purr crashed) which you can attach to your bug report.

Any simpler ways like high verbosity level when opening a patch or similar?
>

Yeah, there's a global -verbose option for that, but last time I checked it
could easily cause troubles by itself. There are other ways to go about
debugging certain issues once we know what happens where and when, but
Jonathan can give better instructions on these. In any case, all of this is
best discussed on the bug tracker so that we have a complete trail of the
process and don't have to go digging through ml archives...

Since I have a lot of GoP on my patches I suspect that it is something
> related to this.
>

Then you submit that patch, or preferably a suitably boiled-down version,
in your bug report.

I'm on Linux Mint 17.3 - 64 bits (based on Ubuntu 14.04).
>

That might also be part of the issue, if Mint uses libraries which aren't
binary-compatible with what's on stock Ubuntu. (I consider that unlikely,
though.)

Albert

-- 
Dr. Albert Gr"af
Computer Music Research Group, JGU Mainz, Germany
Email:  aggraef at gmail.com
WWW:    https://plus.google.com/+AlbertGraef
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20171212/b325c40f/attachment-0001.html>