On 06/08/2016 11:28, John Nelson wrote: > The full crash report is on its way by direct email.
Hi John, Joe & all, from the full crash report: Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libsystem_kernel.dylib 0x00007fff8caf2db6 __psynch_cvwait + 10 1 libsystem_pthread.dylib 0x00007fff91db8728 _pthread_cond_wait + 767 2 libgomp.1.dylib 0x0000000105e1752b gomp_sem_wait + 43 3 libgomp.1.dylib 0x0000000105e1780d gomp_team_barrier_wait_end + 205 4 ??? 0x00007fc48a819400 0 + 140482114065408 Thread 1: 0 libsystem_c.dylib 0x00007fff87d6009e flockfile + 4 1 libsystem_c.dylib 0x00007fff87d69368 vfprintf_l + 28 2 libsystem_c.dylib 0x00007fff87d61885 fprintf + 186 3 jt9 0x00000001002cfae5 0x10027f000 + 330469 4 jt9 0x00000001002b2fa3 0x10027f000 + 212899 5 jt9 0x00000001002a0aa6 0x10027f000 + 137894 6 jt9 0x000000010028b54b 0x10027f000 + 50507 7 libgomp.1.dylib 0x0000000105e15769 gomp_thread_start + 361 Not a great deal of help but my guess is that since the second thread was doing I/O and that it was in a thread at all means that some output operation in the OpenMP parallel execution is causing the problem. It may be a simple as something being written to a protected directory like the CWD or executable directory. Given Claude's report of a file called 'sndump.txt', that might be the culprit although it doesn't seem to be written any more. A likely possibility is a Fortran write to an unopened unit, this creates a file in the CWD and is consistent with the underlying fprintf call trying to lock a file. Another possibility is Fortran code not allowing for long file path names, particularly on Mac OS X where the temporary directory path is very long. In general, if a fixed length string must be used for file paths, allowing ~500 characters should be safe for WSJT-X. 73 Bill G4WJS. ------------------------------------------------------------------------------ _______________________________________________ wsjt-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wsjt-devel
