Hi all,
I'm working on a patch for batch analysis using timbreID and it "sometimes" crashes. I say sometimes, because every one or two attempts it does what it's supposed to do, but it's unpredictable.
I'm on OSX el capitan,10.11.6, and I'm using timbreID from deken. The same crash occurs with pd compiled from git, and with pd-0.48-2.mac.tar.gz
Any hints would be useful :)
Thanks,
Fede
I attach the patch. The lldb output is as follows:
(lldb) target create "/Users/federicocamarahalac/Downloads/Pd-0.48-2.app/Contents/Resources/bin/pd" Current executable set to '/Users/federicocamarahalac/Downloads/Pd-0.48-2.app/Contents/Resources/bin/pd' (x86_64). (lldb) settings set -- target.run-args "atid.pd" (lldb) process launch Process 87868 launched: '/Users/federicocamarahalac/Downloads/Pd-0.48-2.app/Contents/Resources/bin/pd' (x86_64) Cannot connect to server socket err = No such file or directory Cannot connect to server request channel jack server is not running or cannot be started JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock input channels = 2, output channels = 12 Pd-0.48.2 ("") compiled 19:06:28 Aug 12 2018 port 5400 "/Users/federicocamarahalac/Downloads/Pd-0.48-2.app/Contents/Resources/../MacOS/Pd" 5400 Waiting for connection request... ... connected pd(87868,0x7fff75750000) malloc: *** error for object 0x100439648: incorrect checksum for freed object - object was probably modified after being freed. *** set a breakpoint in malloc_error_break to debug Pt_Start() called Process 87868 stopped
- thread #1: tid = 0x44e72e, 0x00007fff96095f06
libsystem_kernel.dylib__pthread_kill + 10, queue = 'com.apple.main-thread', stop reason = signal SIGABRT frame #0: 0x00007fff96095f06 libsystem_kernel.dylib__pthread_kill + 10
libsystem_kernel.dylib`__pthread_kill:
-> 0x7fff96095f06 <+10>: jae 0x7fff96095f10 ; <+20>
0x7fff96095f08 <+12>: movq %rax, %rdi
0x7fff96095f0b <+15>: jmp 0x7fff960907cd ; cerror_nocancel
0x7fff96095f10 <+20>: retq
On 08/20/2018 05:28 PM, Federico Camara Halac wrote:
Hi all,
I'm working on a patch for batch analysis using timbreID and it "sometimes" crashes. I say sometimes, because every one or two attempts it does what it's supposed to do, but it's unpredictable.
I'm on OSX el capitan,10.11.6, and I'm using timbreID from deken. The same crash occurs with pd compiled from git, and with pd-0.48-2.mac.tar.gz
Any hints would be useful :)
how to interact with your patch in order to trigger the problem? what else (data files...) is needed?
i clicked on the big messagebox on the toplevel (without having a ~/voice.wav), and valgrind reports four errors, all of them in the timbreID library.
i've installed timbreID-0.7.7 from deken for Linux-amd64, which has stripped away all symbols and no sources have been uploaded, so I cannot do a fast re-compilation myself.
fgmrdsa IOhannes
Hi IOhannes,
thanks for looking into this.
how to interact with your patch in order to trigger the problem?
what else (data files...) is needed?
i clicked on the big messagebox on the toplevel (without having a ~/voice.wav),
Here's what I do: pd -batch -send ";file symbol $your_audio_file;dbfile symbol $output_database_name" -open atid.pd
Hi Federico,
I've just finished some updates/additions this month so there must be some bugs and I'd love to find them. But I can't get this to crash using Mac OS 10.13.6 and Pd 0.48-2. It seems to run and produce your output database files whether I run Pd in -batch or with the normal GUI. I'll be able to dig into this later this week and see if I can track it down with you if you'd like to stay in touch.
On Mon, Aug 20, 2018 at 3:01 PM Federico Camara Halac camarafede@gmail.com wrote:
Hi IOhannes,
thanks for looking into this.
how to interact with your patch in order to trigger the problem?
what else (data files...) is needed?
i clicked on the big messagebox on the toplevel (without having a ~/voice.wav),
Here's what I do: pd -batch -send ";file symbol $your_audio_file;dbfile symbol $output_database_name" -open atid.pd
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Hi Will,
Thanks so much, yes! I'm puzzled. I've even compiled single-precision fftw and timbreID and still have the crash. It might be my old mac or something I must have in my environment then that I can't really pin down...
Thanks for taking a closer look! I learnt a lot with tID, and it is getting better by the minute. I'd love to contribute in any way
Cheers,
Fede
fdch.github.io/tv
On Aug 20, 2018, at 6:22 PM, William Brent william.brent@gmail.com wrote:
Hi Federico,
I've just finished some updates/additions this month so there must be some bugs and I'd love to find them. But I can't get this to crash using Mac OS 10.13.6 and Pd 0.48-2. It seems to run and produce your output database files whether I run Pd in -batch or with the normal GUI. I'll be able to dig into this later this week and see if I can track it down with you if you'd like to stay in touch.
On Mon, Aug 20, 2018 at 3:01 PM Federico Camara Halac camarafede@gmail.com wrote: Hi IOhannes,
thanks for looking into this.
how to interact with your patch in order to trigger the problem? what else (data files...) is needed?
i clicked on the big messagebox on the toplevel (without having a ~/voice.wav),
Here's what I do: pd -batch -send ";file symbol $your_audio_file;dbfile symbol $output_database_name" -open atid.pd
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
-- William Brent www.williambrent.com
“Great minds flock together” Conflations: conversational idiom for the 21st century
www.conflations.com
On 2018-08-21 01:35, Fede Camara Halac wrote:
Hi Will,
Thanks so much, yes! I'm puzzled. I've even compiled single-precision fftw and timbreID and still have the crash. It might be my old mac or something I must have in my environment then that I can't really pin down...
not necessarily. memory errors are notorious for *not always* breaking the system: depending on memory alignment and (prior) usage, the content of an accessed memory block might contain expected data (mostly all NULLs) or some garbage, leading to crashes.
you would need to compile timpleID with debugging symbols and without stripping, to see where the problems start.
for whatever reasons, timbreID does not use the pd-lib-builder Makefile which would make this very simple, but some self-made one.
mgasrd IOhannes
PS: i was tempted to fix this and open a PR on github, but the repository contains hundred of megabytes of unneccesary data (compiled objects of old versions of the library for multiple OS; zipfiles of data which is also present in the archive,...) which made me bang my head on the table repeatedly so i gave up doing anything.
Yes, I should spend some time incorporating pd-lib-builder and learning how to maintain a repository properly. Hopefully I'll be able to work on those things soon.
On Tue, Aug 21, 2018 at 4:24 AM IOhannes m zmoelnig zmoelnig@iem.at wrote:
On 2018-08-21 01:35, Fede Camara Halac wrote:
Hi Will,
Thanks so much, yes! I'm puzzled. I've even compiled single-precision
fftw and timbreID and still have the crash. It might be my old mac or something I must have in my environment then that I can't really pin down...
not necessarily. memory errors are notorious for *not always* breaking the system: depending on memory alignment and (prior) usage, the content of an accessed memory block might contain expected data (mostly all NULLs) or some garbage, leading to crashes.
you would need to compile timpleID with debugging symbols and without stripping, to see where the problems start.
for whatever reasons, timbreID does not use the pd-lib-builder Makefile which would make this very simple, but some self-made one.
mgasrd IOhannes
PS: i was tempted to fix this and open a PR on github, but the repository contains hundred of megabytes of unneccesary data (compiled objects of old versions of the library for multiple OS; zipfiles of data which is also present in the archive,...) which made me bang my head on the table repeatedly so i gave up doing anything.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Just to update this thread: I'm now using the pd-lib-builder Makefile and have cleaned up the timbreID repo.
Federico - I still can't get your patch to crash...can you write me off list and explain exactly how to duplicate it?
On Tue, Aug 21, 2018 at 4:24 AM IOhannes m zmoelnig zmoelnig@iem.at wrote:
On 2018-08-21 01:35, Fede Camara Halac wrote:
Hi Will,
Thanks so much, yes! I'm puzzled. I've even compiled single-precision
fftw and timbreID and still have the crash. It might be my old mac or something I must have in my environment then that I can't really pin down...
not necessarily. memory errors are notorious for *not always* breaking the system: depending on memory alignment and (prior) usage, the content of an accessed memory block might contain expected data (mostly all NULLs) or some garbage, leading to crashes.
you would need to compile timpleID with debugging symbols and without stripping, to see where the problems start.
for whatever reasons, timbreID does not use the pd-lib-builder Makefile which would make this very simple, but some self-made one.
mgasrd IOhannes
PS: i was tempted to fix this and open a PR on github, but the repository contains hundred of megabytes of unneccesary data (compiled objects of old versions of the library for multiple OS; zipfiles of data which is also present in the archive,...) which made me bang my head on the table repeatedly so i gave up doing anything.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On 8/23/18 10:15 PM, William Brent wrote:
Just to update this thread: I'm now using the pd-lib-builder Makefile and have cleaned up the timbreID repo.
cool. thanks. however and unfortunately, cleaning up a repo is not a very easy task. but at least it's a good start :-)
since cloning the repo will download the entire history of it, just removing big files with a commit doesn't hep very much: they are still all there.
i guess the completely proper way would be:
- remove all the binaries and example data from the repositories *history*
- use git-lfs for the example data.
gfmards IOhannes
Thanks for the advice IOhannes. I'll look into that aspect of things next...
On Fri, Aug 24, 2018 at 2:32 PM IOhannes m zmölnig zmoelnig@iem.at wrote:
On 8/23/18 10:15 PM, William Brent wrote:
Just to update this thread: I'm now using the pd-lib-builder Makefile and have cleaned up the timbreID repo.
cool. thanks. however and unfortunately, cleaning up a repo is not a very easy task. but at least it's a good start :-)
since cloning the repo will download the entire history of it, just removing big files with a commit doesn't hep very much: they are still all there.
i guess the completely proper way would be:
- remove all the binaries and example data from the repositories *history*
- use git-lfs for the example data.
gfmards IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
-
Fede Camara Halac -
Federico Camara Halac
-
IOhannes m zmoelnig -
IOhannes m zmölnig
-
William Brent