Forums > Dev

dylib access freezes max

Jun 15 2011 | 2:21 pm

Dear Max-Community,

for the problem below I sent you a testpatch and the external as well as the sources of the externals inside the this link:

I implemented an external using the xml-parser of this community
See the xml-folder for the implementation.
You need to copy all dylibs to /usr/lib in sudo-mode.
All works fine.

Also since long time I am using an external for copy files (filesys with ‘cp’ command)
Sources in the filesys-folder.

Please open the patch and follow the steps described. The combination of the two patches crashes Max.

It is hard to understand, why Max crashes here (in general) and even more weird: why is Max crashing only after the second time…?
It looks like a collosion of the dylibs… but I don’t have any idea of the dylib system of Max@Mac
The crash: Max freezes… it is not a crash to be more precise (colorball shows up, nothing happens)

Under Windows I was using 2.7.8 of libxml and I had problems with the combination of libxml/zlib and quicktime (
This I could resolve copying the dll into the app folder after building an Application (and not inlcude it into the ‘sources’).

Mac: MacBookPro4,1, BootROM MBP41.00C1.B03, 2 processors, Intel Core 2 Duo, 2.5 GHz, 4 GB
Snow: 10.6.7
Max: 5.1.8
SDK: 5.1.6

Crashreport attached!

For any help I will be grateful
Thanks in advance

Best Regards

  1. crashreport
Jun 21 2011 | 6:01 pm

I can reproduce your problem. Some kind of apparent deadlock issue.

At first glance, I don’t see any problems with your code for the file copying. There is no source code for the xmlparser though. I can only speculate that some resource in that object is not being properly released.


Jun 21 2011 | 10:59 pm

Hi Tim,
thanks for your response.

in this zip is a subfolder called xml and there you may find the xmlparser.c

The problem does not occur on Windows!


Jun 23 2011 | 6:02 pm

A quick look… Are you sure that this memory

char xmlResult[1024];

is large enough? I don’t see any safeguards to make sure that the memory isn’t being accessed past the end of this. As a minimum you could use strncpy(), or Max’s strncpy_zero(), instead of strcpy().

Are you debugging using the Runtime? Assuming yes, you could turn on Xcode’s "Enable Guard Malloc" feature. It will run _very_ slowly, but often crashes at the point that out-of-bounds memory is accessed rather than at some random point later on.


Jul 24 2011 | 3:17 am

Hi Tim,
thank you for your answer!
But why is it all working on windows?
The problem occurs regularly in the same moment of the process, but if it would be a pointer access violation, it would appear in different situations, wouldn’t it?

I tried with debug mode too, but there was again the inifitive-loop phenomenon.


Aug 10 2011 | 3:28 pm

Hi Tim,

I tried to change the char xmlResult to 4096, as well I am using strncopy_zero with this length in xmlparser.c. Also I attached the console output of xCode in GuardMalloc-Mode. There is still no change.
In the line 242 of filesys.c
errCode = path_copyfile(srcpath, srcfilename, dstpath, dstfilename);
the Debugger tells me: GDB: stepping into… and that’s it, no response anymore.
Is there anything else I can do? I am thinking, that it could be a problem with the file access. For me it looks like
the copy process is started (the file also is generated as a hidden copy-in-process-file), but it is ending in one step in an infinitive loop.

Thanks in advance

Aug 12 2011 | 4:29 pm

The console doesn’t tell me much… So it just spins forever rather than actually crashing? Speculating (but maybe it will spark an idea for you), is the file you are copying properly terminated? Is it possibly still open for writing by another process?

Instead of using path_copyfile(), you could try substituting your own code to copy the file contents and see what happens. It should be pretty easy to do with fopen() and friends.

Sorry I can’t dive in for an extra-detailed analysis right now — we’ve got a lot cooking still to do on Max 6.


Sep 19 2011 | 10:31 pm


problem solved finally… I am using the standard-copy function with fopen/getc/putc to copy the file and now it works. I think it is related to the path_copyfile()-Method and a flag should be the access-option in the method-signature – one day, after Max6.

Thanks for all the help and good luck with Mr. 6!

Sep 20 2011 | 1:00 pm

After retesting I realized, that the bug was resolved only by recompiling the external with the copy-process with the 5.1.7 SDK

Thanks again for the support!

Viewing 9 posts - 1 through 9 (of 9 total)

Forums > Dev