Hi Steve, I was about to write to you along the same lines. The copies of nhash.h and nhash.c in .../wsjtx_exp/lib have been used only for building the executable testmsk, not for wsprx. I was clearly on the wrong track yesterday.
It turns out, I believe, that the problem is entirely elsewhere. Under certain conditions an undefined value for TRperiod could be passed to function getfile(), which is used to read *.wav files from disk. As a consequence a big memory segment could be zeroed when this statement (line 56 of getfile.cpp) was executed: memset(jt9com_.d2,0,2*npts); I have now protected against this occurrence. Please try building and testing revision 5831. -- Joe, K1JT On 8/30/2015 10:15 AM, Steven Franke wrote: > Joe - > > In perusing the wsjtx_exp code this morning, I noticed two things: > > 1. All references to nhash.c in CMakeLists.txt are to the version in > /lib/wsprd - so it seems that changes in /lib/nhash.c are not going to make > any difference. If this is working for you, then perhaps we can just delete > the nhash.c/nhash.h in /lib? > > 2. in /lib/nhash.h, length is declared size_t in nhash and uint32_t in > nhash_, whereas in /lib/nhash.c is it uint32_t in nhash.c and uint32_t in > nhash_ > > I’m guessing that item 2 is not the problem due to item 1? > > I think that we need to resolve the differences between the two nhash.c’s and > get rid of one of them. > > Steve > > ------------------------------------------------------------------------------ > _______________________________________________ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel ------------------------------------------------------------------------------ _______________________________________________ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel