Yes, that’s it. I think that this is my fault, though I’m not sure how it came about.
If you look at nhash.c back in wsprx: uint32_t nhash_( const void *key, int *length0, uint32_t *initval0) compared to the current nhash.c in wsjtx: uint32_t nhash_( const void *key, size_t length, uint32_t initval) I am using nhash.c in wsprd.c, so if you change it to pass all arguments by reference, then wsprd_utils.c and maybe wsprd.c will need to be fixed up... Steve k9an > On Jun 10, 2015, at 9:03 AM, Bill Somerville <g4...@classdesign.com> wrote: > > Hi again, > > further update - looks like the C function nhash_() is receiving args by > value but is called from Fortran which passes by reference. > > I will see if I can sort it out. > > 73 > Bill > G4WJS. > > On 10/06/2015 14:49, Bill Somerville wrote: >> Hi Steve & probably Joe, >> >> I have a change to deal with this, I think. But when I tried to test it >> out by sending a WSPR Tx from a local instance of WSJT-X using the call >> PJ4/K1ABC and grid FK52ud the first Tx goes Ok but WSJT-X crashes with >> the following stack trace just as it is about to transmit the 2nd message: >> >> Program received signal SIGSEGV, Segmentation fault. >> 0x004979df in nhash_ (key=0x28c820, length=2642428, initval=6623596) >> at C:\Users\bill\src\wsjt\lib\wsprd\nhash.c:224 >> 224 b += k[1]; >> (gdb) p k >> $1 = (const uint32_t *) 0x293ffc >> (gdb) bt >> #0 0x004979df in nhash_ (key=0x28c820, length=2642428, initval=6623596) >> at C:\Users\bill\src\wsjt\lib\wsprd\nhash.c:224 >> #1 0x0048c8d8 in hash ( >> string=<error reading variable: Cannot access memory at address >> 0x28ca14>, l >> en=9, ihash=0, _string=12) at C:\Users\bill\src\wsjt\lib\hash.f90:10 >> #2 0x00487be9 in wqencode (msg=..., ntype=2673464, data0=..., _msg=22) >> at C:\Users\bill\src\wsjt\lib\wqencode.f90:48 >> #3 0x0047606f in genwspr (message=..., msgsent=..., itone=..., _message=22, >> _msgsent=22) at C:\Users\bill\src\wsjt\lib\genwspr.f90:21 >> #4 0x00436c69 in MainWindow::guiUpdate (this=0x28f8c0) >> at C:\Users\bill\src\wsjt\mainwindow.cpp:1987 >> #5 0x005d8425 in QtPrivate::FunctorCall<QtPrivate::IndexesList<>, >> QtPrivate::Li >> st<>, void, void (MainWindow::*)()>::call(void (MainWindow::*)(), >> MainWindow*, v >> oid**) (f= >> (void (MainWindow::*)(MainWindow * const)) 0x4353f6 >> <MainWindow::guiUpdate() >>> , o=0x28f8c0, arg=0x28cf9c) >> at C:/Tools/Qt/5.2.1/mingw48_32/include/QtCore/qobjectdefs_impl.h:508 >> #6 0x005dbe76 in QtPrivate::FunctionPointer<void >> (MainWindow::*)()>::call<QtPri >> vate::List<>, void>(void (MainWindow::*)(), MainWindow*, void**) (f= >> (void (MainWindow::*)(MainWindow * const)) 0x4353f6 >> <MainWindow::guiUpdate() >>> , o=0x28f8c0, arg=0x28cf9c) >> at C:/Tools/Qt/5.2.1/mingw48_32/include/QtCore/qobjectdefs_impl.h:527 >> #7 0x005d9bd3 in QtPrivate::QSlotObject<void (MainWindow::*)(), >> QtPrivate::List >> <>, void>::impl(int, QtPrivate::QSlotObjectBase*, QObject*, void**, bool*) ( >> which=1, this_=0x18534150, r=0x28f8c0, a=0x28cf9c, ret=0x0) >> at C:/Tools/Qt/5.2.1/mingw48_32/include/QtCore/qobject_impl.h:149 >> #8 0x6ba35685 in QtPrivate::QSlotObjectBase::call (this=0x18534150, >> r=0x28f8c0, a=0x28cf9c) >> at ../../include/QtCore/../../src/corelib/kernel/qobject_impl.h:132 >> #9 0x6b9467c7 in QMetaObject::activate (sender=0x28fbb0, signalOffset=3, >> local_signal_index=0, argv=warning: (Internal error: pc 0x0 in read >> in psymt >> ab, but not in symtab.) >> >> 0x0) at kernel\qobject.cpp:3561 >> #10 0x6b946232 in QMetaObject::activate (sender=0x28fbb0, m=0x6bbc2f44, >> local_signal_index=0, argv=warning: (Internal error: pc 0x0 in read >> in psymt >> ab, but not in symtab.) >> >> 0x0) at kernel\qobject.cpp:3444 >> #11 0x6b99e248 in QTimer::timeout (this=0x28fbb0) >> at .moc\debug\moc_qtimer.cpp:189 >> #12 0x6b94a19c in QTimer::timerEvent (this=0x28fbb0, e=0x28d6dc) >> at kernel\qtimer.cpp:255 >> #13 0x6b940daa in QObject::event (this=0x28fbb0, e=0x28d6dc) >> at kernel\qobject.cpp:1128 >> #14 0x0c5adeb1 in QApplicationPrivate::notify_helper (this=0x15c4c1e8, >> receiver=0x28fbb0, e=0x28d6dc) at kernel\qapplication.cpp:3482 >> #15 0x0c5ab7cd in QApplication::notify (this=0x28fd34, receiver=0x28fbb0, >> e=0x28d6dc) at kernel\qapplication.cpp:2903 >> #16 0x6b91b91c in QCoreApplication::notifyInternal (this=0x28fd34, >> receiver=0x28fbb0, event=0x28d6dc) at kernel\qcoreapplication.cpp:881 >> #17 0x6b9bf427 in QCoreApplication::sendEvent (receiver=0x28fbb0, >> event=0x28d6dc) >> at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:232 >> #18 0x6b965747 in QEventDispatcherWin32Private::sendTimerEvent ( >> this=0x15b199d8, timerId=15) at kernel\qeventdispatcher_win.cpp:585 >> #19 0x6b965012 in qt_internal_proc (hwnd=0x533656 <hiqsdr_set_freq+93>, >> message=275, wp=15, lp=0) at kernel\qeventdispatcher_win.cpp:426 >> #20 0x74d48e71 in USER32!CallWindowProcA () >> from C:\windows\SysWOW64\user32.dll >> #21 0x74d490d1 in USER32!CallWindowProcA () >> from C:\windows\SysWOW64\user32.dll >> #22 0x74d4a66f in USER32!GetOpenClipboardWindow () >> from C:\windows\SysWOW64\user32.dll >> #23 0x74d4a6e0 in USER32!DlgDirListComboBoxW () >> from C:\windows\SysWOW64\user32.dll >> #24 0x6b9662cb in QEventDispatcherWin32::processEvents (this=0x15c4bea8, >> flags=...) at kernel\qeventdispatcher_win.cpp:756 >> #25 0x6285dbc6 in QWindowsGuiEventDispatcher::processEvents >> (this=0x15c4bea8, >> flags=...) at qwindowsguieventdispatcher.cpp:80 >> #26 0x6b919a20 in QEventLoop::processEvents (this=0x28f820, flags=...) >> at kernel\qeventloop.cpp:136 >> #27 0x6b919cbb in QEventLoop::exec (this=0x28f820, flags=...) >> at kernel\qeventloop.cpp:212 >> #28 0x6b91bf56 in QCoreApplication::exec () >> at kernel\qcoreapplication.cpp:1134 >> #29 0x034bb05a in QGuiApplication::exec () at >> kernel\qguiapplication.cpp:1332 >> #30 0x0c5ab187 in QApplication::exec () at kernel\qapplication.cpp:2707 >> #31 0x00468d8b in _fu111___ZSt4cerr () at >> C:\Users\bill\src\wsjt\main.cpp:200 >> >> A quick analysis seems to show something going wrong with the generation >> of the hashcode for the 2nd message to be sent. Before I get to deep >> into this perhaps one of you, who knows the message generation code, can >> say quickly why this is failing. >> >> 73 >> Bill >> G4WJS. >> >> On 10/06/2015 13:56, Bill Somerville wrote: >>> On 10/06/2015 13:19, Steven Franke wrote: >>>> Bill, >>> Hi Steve, >>>> I noticed that callsigns retrieved from the hashtable are not being >>>> displayed in the spots window. The callsign is visible in ALL_WSPR.TXT, >>>> with the customary <callsign> notation, however the callsign field is >>>> blank in the spots window. >>> That is probably due to the decodes window processing text as Qt rich >>> text which is a subset of HTML 4. The < and > characters will need escaping. >>> >>> I will commit something shortly. >>>> Steve k9an >>> 73 >>> Bill >>> G4WJS. >>> >>> ------------------------------------------------------------------------------ >>> _______________________________________________ >>> 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 > > > ------------------------------------------------------------------------------ > _______________________________________________ > 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
