dylib access freezes max
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 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.
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)
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 any help I will be grateful
Thanks in advance
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.
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!
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.
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.
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
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.
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
Thanks again for the support!