Johannes

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.

Also since long time I am using an external for copy files (filesys with 'cp' command)

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 (jit.qt.movie)

https://cycling74.com/forums/quicktime-vs-zlib-on-windows7

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

for the problem below I sent you a testpatch and the external as well as the sources of the externals inside the this link:
http://tryek.de/content/dylib-prob.zip

I implemented an external using the xml-parser of this community http://xmlsoft.org/
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.

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 (jit.qt.movie)
https://cycling74.com/forums/quicktime-vs-zlib-on-windows7
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

For any help I will be grateful
Thanks in advance

dylib-access-freezes-max

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.

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.

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

A quick look... Are you sure that this memory

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.

A quick look...   Are you sure that this memory

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.

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.

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 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.

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.

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.cerrCode = 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.

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.

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.

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!

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

dylib access freezes max