Dear Bill,

There you go:

(gdb)  b get_wspr_channel_symbols if symbols==0
Breakpoint 1 at 0x1ad48: file /root/src/wsjtx/src/lib/wsprd/wsprsim_utils.c, 
line 167.
(gdb) r
Starting program: /root/src/wsjtx/build/Debug/wsprd -f 7.0386 
wspr_7038600160310_1944.wav
Cannot access memory at address 0x0
Cannot access memory at address 0x0
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabi/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x0001b4fc in get_wspr_channel_symbols (rawmessage=0x210d8 "I2GPG JN45 33", 
hashtab=0xb68dc008 "", symbols=0x0) at 
/root/src/wsjtx/src/lib/wsprd/wsprsim_utils.c:309
309             symbols[i]=2*channelbits[i]+pr3[i];
(gdb) bt
#0  0x0001b4fc in get_wspr_channel_symbols (rawmessage=0x210d8 "I2GPG JN45 33", 
hashtab=0xb68dc008 "", symbols=0x0) at 
/root/src/wsjtx/src/lib/wsprd/wsprsim_utils.c:309
#1  0x00018e48 in main (argc=4, argv=0xbefff224) at 
/root/src/wsjtx/src/lib/wsprd/wsprd.c:1088
(gdb) 


@Mike:

I did the same with the static variable and it looks the same:

(gdb) b get_wspr_channel_symbols if symbols==0
Breakpoint 1 at 0x1ad40: file /root/src/wsjtx/src/lib/wsprd/wsprsim_utils.c, 
line 167.
(gdb) r
Starting program: /root/src/wsjtx/build/Debug/wsprd -f 7.0386 
wspr_7038600160310_1944.wav
Cannot access memory at address 0x0
Cannot access memory at address 0x0
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabi/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x0001b4f4 in get_wspr_channel_symbols (rawmessage=0x210d8 "I2GPG JN45 33", 
hashtab=0xb68dc008 "", symbols=0x0) at 
/root/src/wsjtx/src/lib/wsprd/wsprsim_utils.c:309
309             symbols[i]=2*channelbits[i]+pr3[i];
(gdb) bt
#0  0x0001b4f4 in get_wspr_channel_symbols (rawmessage=0x210d8 "I2GPG JN45 33", 
hashtab=0xb68dc008 "", symbols=0x0) at 
/root/src/wsjtx/src/lib/wsprd/wsprsim_utils.c:309
#1  0x00018e3c in main (argc=4, argv=0xbefff224) at 
/root/src/wsjtx/src/lib/wsprd/wsprd.c:1088
(gdb) 

73 de PA7T / Clemens

Am 15.03.2016 um 00:16 schrieb Bill Somerville <[email protected]>:

> Hi Clemens,
> 
> ok, we need to dig deeper then.
> 
> Let's set a break point at the start of the function that crashes and 
> see if the 'symbols' pointer is correct at the start. Run the test with 
> the debug version of wsprd under gdb again but this time type:
> 
>   b get_wspr_channel_symbols if symbols==0
> 
> before you type the 'r' command to start the program. If this break 
> point gets hit then print a stack trace as before using 'bt'. If it 
> doesn't get hit then I expect the program will halt with a SEGV as before.
> 
> 73
> Bill
> G4WJS.
> 
> On 14/03/2016 19:44, Clemens Heese wrote:
>> Dear Bill,
>> 
>> does not help :(
>> 
>> root@red-pitaya:~/tmp# ulimit -s
>> 8192
>> root@red-pitaya:~/tmp# wsprd -f 7.0386 wspr_7038600160310_1944.wav
>> Segmentation fault
>> root@red-pitaya:~/tmp# ulimit -s unlimited
>> root@red-pitaya:~/tmp# wsprd -f 7.0386 wspr_7038600160310_1944.wav
>> Segmentation fault
>> root@red-pitaya:~/tmp# ulimit -s
>> unlimited
>> root@red-pitaya:~/tmp# wsprd -f 7.0386 wspr_7038600160310_1944.wav
>> Segmentation fault
>> root@red-pitaya:~/tmp#
>> 
>> 73 de PA7T / Clemens
>> 
>> 
>> Am 14.03.2016 um 20:37 schrieb Bill Somerville <[email protected]>:
>> 
>>> On 14/03/2016 19:04, Clemens Heese wrote:
>>>> Starting program: /root/wsjtx/build/Debug/wsprd -f 7.0386 
>>>> wspr_7038600160310_1944.wav
>>>> Cannot access memory at address 0x0
>>>> [Thread debugging using libthread_db enabled]
>>>> Using host libthread_db library "/lib/arm-linux-gnueabi/libthread_db.so.1".
>>>> 
>>>> Program received signal SIGSEGV, Segmentation fault.
>>>> 0x0001b4fc in get_wspr_channel_symbols (rawmessage=0x210d8 "I2GPG JN45 
>>>> 33", hashtab=0xb68e3008 "", symbols=0x0)
>>> Hi Clemens,
>>> 
>>> the crash is because the 'symbols' argument to
>>> 'get_wspr_channel_symbols()' is null. I don't see how a program error
>>> could cause that to happen so I think there is a problem elsewhere. It
>>> may be a stack size problem. Try increasing the process stack size limit:
>>> 
>>>   ulimit -s
>>>   ulimit -s unlimited
>>>   ulimit -s
>>> 
>>> and see if that helps. Check that the limit actually changes by
>>> comparing the results of the first and last command above.
>>> 
>>> 
> 
> 
> ------------------------------------------------------------------------------
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
> _______________________________________________
> wsjt-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel


------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
_______________________________________________
wsjt-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Reply via email to