Hello everyone,
Thanks Miller for the suggestions. I tried loading the parent patch with an empty abstraction in place of the one that is called 2197 times (as mentioned, this repeatedly called abstraction is very small, but has two inlets, two outlets, and four receive objects) and the parent patch loaded fine. I noticed while trying to load the original parent patch (with the repeated abstraction in place) with the -verbose flag, that the parent pd window scrolls as if it's loading many of the instances being called (trying and failing to find the .dll, finding the .pd) for about fifteen seconds before pd dies. I also noticed that after I rebuilt the parent patch, it dies at a different point (presumably because I put the objects on the screen in a different order than I did when I initially built the patch). To me, this suggests a memory problem, but, as I mentioned, my system resource meter doesn't show any problems. Could the resource meter just be reacting too slowly to show the dip in memory? Would pd run out of memory before my system actually does (I'm ignorant about how operating systems allocate memory to programs)? Any suggestions?
Thanks again, Greg NYU
Miller Puckette wrote:
Hi all,
Well, this is every software developer's nightmare...
To start with, I'd suggest trying to load the patch with dummies in place of the abstractions, and with the "-noloadbang" flag. There could be some limit I don't know about in Pd's ability to handle patches with huge numbers of subwindows (or any of a host of other possible problems..)
I do know that Pd is ungraceful when it runs out of memory; it's sometimes hard to find out when that happens...
cheers Miller
On Tue, Aug 21, 2001 at 02:35:58AM -0400, Greg Rippin wrote:
Hello all,
I have been working for some time on a patch that does a realtime harmonic analysis of an incoming MIDI stream and constructs probability tables for creating second-order markov chains based on the input. The patch is fairly large and complex; the probability calculating abstraction (fairly small in itself) is called 13x13x13 times.
Recently, pd has occasionally died when I try to open this patch, but I could get it to open after a few failed attempts. Now, quite suddenly, it won't open at all; pd generates an invalid page fault whenever I try to load this patch. It opens all other patches without trouble. Most puzzling to me is that I haven't actually made any changes to the patch; I added some comments to the abstractions that are called by the parent patch, but made no functional changes immediately before this started to happen. I thought that perhaps the file was corrupt; I rebuilt the patch from it's constituent parts, it worked perfectly. I saved it under a different filename, closed it, tried to reopen it, and got the same error message. I even checked my resource meters, and nothing (memory, etc.) seems to dip when trying to open this patch. I'm stumped.
What could I have done wrong to cause behavior like this? I'm running pd .33 patch 1 with the iemlib extensions on win 98. The error message I get is:
PD caused an invalid page fault in module PD.DLL at 015f:10046e98. Registers: EAX=00960008 CS=015f EIP=10046e98 EFLGS=00210293 EBX=00000150 SS=0167 ESP=0063da90 EBP=0063dab0 ECX=00962838 DS=0167 ESI=00000013 FS=0fbf EDX=0309f00c ES=0167 EDI=00000014 GS=0000 Bytes at CS:EIP: 8b 49 04 89 4a 04 8b 4d f0 8d 0c f9 89 4a 08 89 Stack dump: 03100df0 00000200 0309f050 00000000 00962798 00000150 0309f00c 00000040 00960138 10042d20 00960138 00000003 03100df0 0309f050 00000110 00000200
Any help is greatly appreciated, Greg
-- Greg Rippin, Graduate Assistant Music Technology Program New York University 35 West 4th Street, Suite 777 New York, NY 10012
phone 212-998-5422 fax 212-995-4043 musictechgrad.info@nyu.edu www.nyu.edu
-- Greg Rippin, Graduate Assistant Music Technology Program New York University 35 West 4th Street, Suite 777 New York, NY 10012
phone 212-998-5422 fax 212-995-4043 musictechgrad.info@nyu.edu www.nyu.edu