problems and crashes - "warning: settings multiply defined" (on new hardware and OS - Debian 8 64-bit)
Hi everybody,
I'm having issues with a pretty complex patch that I have written within several years - originally with pd-extended and Ubuntu 11.10 (32-bit - AMD CPU). Now I'm trying to port this to an Up-Board with an Intel CPU and Debian Jessie (64-bit).
I have installed (almost) all libraries successfully. All patches and abstractions are loading successfully (except for [toxy/tot] and [iemlib/mp3play~]).
Here's my problem:
The patch(es) start up (loading over 600MB of samples) and sometimes actually work(s) fine but mostly it crashes during or after the startup. When it actually does start up it runs, sounds and responds just like the previous hardware with the old pd-extended and Ubuntu 11.10.
However, on the pd-window I'm getting thousands of these messages:
"warning: settings multiply defined"
('settings' is a table that holds most of the global settings of the patch(es))
Now I am wondering what the "warning: . multiply defined" means.
I'm usually getting messages like this if I created a table twice by mistake. When using "Find" I only get one single table as my search result. Also that same patch doesn't give me this error on my older hardware and it never crashes. I have been running this patch with the old OS and the AMD hardware with pd-extended on more than 100 units for more than 5 years - no issues!
I am now trying to eliminate more and more parts or abstractions from the patch to see when the error messages stop. Obviously this takes forever since I have already put years of work in there.
Knowing what the "warning: . multiply defined" means would probably speed up the search.
I'd absolutely appreciate any input or idea where to search.
Thanks! Ingo
OK,
one thing I found out now. As opposed to the old pd-extended the vanilla 0.46.2 that came with Jessie seems to see tables that were opened from a different patch in a separate process.
After renaming the "settings" table in the second main patch that runs Gem (while the other one runs the audio part) the error messages disappeared. Does that mean that patches that were opened in a separate process are being seen as one big patch? And all tables are available from anywhere?
That would require some major changes in the patch(es) ...
Ingo
I'm having issues with a pretty complex patch that I have written within several years - originally with pd-extended and Ubuntu 11.10 (32-bit - AMD CPU). Now I'm trying to port this to an Up-Board with an Intel CPU and Debian Jessie (64-bit).
I have installed (almost) all libraries successfully. All patches and abstractions are loading successfully (except for [toxy/tot] and [iemlib/mp3play~]).
Here's my problem:
The patch(es) start up (loading over 600MB of samples) and sometimes actually work(s) fine but mostly it crashes during or after the startup. When it actually does start up it runs, sounds and responds just like the previous hardware with the old pd-extended and Ubuntu 11.10.
However, on the pd-window I'm getting thousands of these messages:
"warning: settings multiply defined"
('settings' is a table that holds most of the global settings of the patch(es))
Now I am wondering what the "warning: . multiply defined" means.
I'm usually getting messages like this if I created a table twice by mistake. When using "Find" I only get one single table as my search result. Also that same patch doesn't give me this error on my older hardware and it never crashes. I have been running this patch with the old OS and the AMD hardware with pd-extended on more than 100 units for more than 5 years - no issues!
I am now trying to eliminate more and more parts or abstractions from the patch to see when the error messages stop. Obviously this takes forever since I have already put years of work in there.
Knowing what the "warning: . multiply defined" means would probably speed up the search.
I'd absolutely appreciate any input or idea where to search.
Thanks! Ingo
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On 09/21/2017 01:58 PM, Ingo wrote:
OK,
one thing I found out now. As opposed to the old pd-extended the vanilla 0.46.2 that came with Jessie seems to see tables that were opened from a different patch in a separate process.
i'm not sure what that you mean by that.
if you start two instances of Pd, they will have separate namespaces (so you can have a [table settings] in both, and they won't collide.
if you start two patches by double-clicking them in your file manager, then you will only start a *single* Pd instance, so you can only have a single instance of [table settings].
gfmards IOhannes
That's what I thought, too. And that's the way it was before. But earlier today when I started two instances separately (by double clicking a .desktop starter or putting two .desktop starters in a autostart folder) any table in each instance was readable from the other instance.
I have deleted the table in the second instance and the warning disappeared but I could still read the values of a single table of the first instance in the second instance. That absolutely doesn't make any sense to me.
I just checked it again and the table was NOT readable now (as expected). This morning it was, though! I had been starting the patches from two .desktop starters in /etc/xdg/autostart.
It could be possible that when the patches crashed and I restarted them that they might have still be running. It's raher confusing to me that it did it earlier today but not right now. Maybe I did restart them by double clicking on the patches instead of the starters???
Anyway, that wasn't the source of my crashes. After having renamed the tables in question the crashes were still there. I'll have to further investigate in both issues.
Thanks anyway! Ingo
one thing I found out now. As opposed to the old pd-extended the vanilla 0.46.2 that came with Jessie seems to see tables that were opened from a different patch in a separate process.
i'm not sure what that you mean by that.
if you start two instances of Pd, they will have separate namespaces (so you can have a [table settings] in both, and they won't collide.
if you start two patches by double-clicking them in your file manager, then you will only start a *single* Pd instance, so you can only have a single instance of [table settings].
gfmards IOhannes
On 2017-09-21 21:42, Ingo wrote:
That's what I thought, too. And that's the way it was before. But earlier today when I started two instances separately (by double clicking a .desktop starter or putting two .desktop starters in a autostart folder) any table in each instance was readable from the other instance.
depends on what your desktop starter is actually doing.
e.g. the desktop starter that comes with Debian, will actually launch the pd-gui which has all the logic to prevent a second startup.
so clicking 4 times on the desktop starter, will only fire up a single instance of Pd. this is by design.
otoh, if you created the starter yourself and used "/usr/bin/pd" as the executable, then you should have multiple instances running.
finally it is rather easy to check: how many Pd-consoles do you have open? each instance will come with a separate console. so if there's only a single Pd "main" window, then you are only running a single instance. another check is to just <kbd>Control</kbd>-<kbd>Shift</kbd>-<kbd>Q</kbd> (aka: quit) your patch. if all windows close (including the "other" main patch), then you were running a single instance.
It could be possible that when the patches crashed and I restarted them that they might have still be running. It's raher confusing to me that it did it earlier today but not right now. Maybe I did restart them by double clicking on the patches instead of the starters???
this i don't know. usually my "desktop-starters" (well, the autostarts) do:
- call a *script* (rather than start Pd itself)
the script does:
- kill running instances of Pd
- start up all instances of Pd i need (backgrounding all but the last)
Anyway, that wasn't the source of my crashes. After having renamed the tables in question the crashes were still there. I'll have to further investigate in both issues.
run the crashing instance of Pd through gdb and get a backtrace to see where it crashes. (use Pd's "-nrt" flag when running through gdb to avoid the watchdog cluttering the gdb output.)
btw, if all Pd patches shut down during the crash, chances are high that you are indeed only running a single instance of Pd.
fgmasd IOhannes
I must have been running a single instance when I got the warnings. I had the folder with the patches open and must have clicked onto the patches insted of the starters. It works as expected with my desktop starters.
The starters do start with /user/bin/pd followed by the flags and the patch directory and name.
When it crashes like this only one instance crashes. When I had the table errors all patches crashed. So, unfortunately the error message was just a mistake of mine starting the patches the wrong way ... :-(
That means I'll have to keep trying to find out what's wrong. Not easy if you have been writing on a single huge patch for almost 10 years that runs perfectly on an older OS and hardware with an older Pd version ...
run the crashing instance of Pd through gdb and get a backtrace to see where it crashes. (use Pd's "-nrt" flag when running through gdb to avoid the watchdog cluttering the gdb output.)
I'll give that a try! Though I not not run Pd with a debugger before. I might get back to you if that gives me a hard time.
Thanks a lot, IOhannes! Ingo
-----Original Message----- From: Pd-list [mailto:pd-list-bounces@lists.iem.at] On Behalf Of IOhannes m zmoelnig Sent: Friday, September 22, 2017 9:46 AM To: pd-list@lists.iem.at Subject: Re: [PD] problems and crashes - "warning: settings multiply defined" (on new hardware and OS - Debian 8 64-bit)
On 2017-09-21 21:42, Ingo wrote:
That's what I thought, too. And that's the way it was before. But earlier today when I started two instances separately (by double clicking a .desktop starter or putting two .desktop starters in a autostart folder) any table in each instance was readable from the other
instance.
depends on what your desktop starter is actually doing.
e.g. the desktop starter that comes with Debian, will actually launch the pd- gui which has all the logic to prevent a second startup.
so clicking 4 times on the desktop starter, will only fire up a single instance of Pd. this is by design.
otoh, if you created the starter yourself and used "/usr/bin/pd" as the executable, then you should have multiple instances running.
finally it is rather easy to check: how many Pd-consoles do you have open? each instance will come with a separate console. so if there's only a single Pd "main" window, then you are only running a single instance. another check is to just <kbd>Control</kbd>-<kbd>Shift</kbd>-<kbd>Q</kbd> (aka: quit) your patch. if all windows close (including the "other" main patch), then you were running a single instance.
It could be possible that when the patches crashed and I restarted them that they might have still be running. It's raher confusing to me that it did it earlier today but not right now. Maybe I did restart them by double clicking on the patches instead of the starters???
this i don't know. usually my "desktop-starters" (well, the autostarts) do:
- call a *script* (rather than start Pd itself) the script does:
- kill running instances of Pd
- start up all instances of Pd i need (backgrounding all but the last)
Anyway, that wasn't the source of my crashes. After having renamed the tables in question the crashes were still there. I'll have to further investigate in both issues.
run the crashing instance of Pd through gdb and get a backtrace to see where it crashes. (use Pd's "-nrt" flag when running through gdb to avoid the watchdog cluttering the gdb output.)
btw, if all Pd patches shut down during the crash, chances are high that you are indeed only running a single instance of Pd.
fgmasd IOhannes
-
Ingo -
IOhannes m zmoelnig -
IOhannes m zmölnig