Hi Don > 1. Maybe you could diff the source with the next earlier version that does > work?
The crash occures at a caesura ornament which you implemented in a very recent version. Testing against older versions won't help therefore. I've let my instable version run inside the gnu debugger. I found that the crash occures in a (library-) function called z_wnew() inside a call of write() in line 13910 of pmx2341.for and I poked a bit around in the code and stack neighborhood of this place. The line is passed many times. At the pass when the crash occures the variable "ioctup" shows the value 306781831 while at the other passes I've only seen things like 1, 0, -1... When I reset the value to zero just before this pass (if I counted right its the 99th) the program continues without failing. Inspecting the stack I see that the value of "ioctup" comes from the variable "ioff" witch gets in turn its value from "islhgt" being a parameter of "putorn()" (->remember that an "oc" caused the crash). This gets set by the variable "islhgt" one stack level (function call) above which seems to be "make2bar()". At the start of this procedure I see a decent value of "islhgt" at most calls, sometimes a strange one like that one above. And in that single run, where the crash occures, the strange value persists until the call of "putorn". Beyond this point I didn't hunt since I do not know much about fortran and even less about internals of pmx... The strange value of "islhgt" could be a hint of an improper initialisation of that variable. But I also observed that tracing the binary on a change of this variable stops at various unexpected places. I havn't got that much experience with tracing features of gdb but this looks to me like a sign of an improper initialisation of a pointer elsewhere which leads to an overwriting of "islhgt" (ugh). regards Bernhard _______________________________________________ TeX-music mailing list [EMAIL PROTECTED] http://sunsite.dk/mailman/listinfo/tex-music
