Seg fault with Debian waveforms library and AD2

[Torfey]

I had a working Debian 8 production system using python2.7 to talk to an Analog Discovery 2. I decided to update the .deb packages to be current and now I get "Segmentation fault" "stack smashing detected" when I try to start my python program.

I was using the amd64.deb files:

• digilent.adept.runtime 2.16.6
• digilent.waveforms 3.5.4  (for the libdwf.so file)

Upgraded to

• digilent.adept.runtime 2.17.1
• digilent.waveforms 3.7.5

Also on the system is digilent.adept.utilities 2.2.1.

I tested just upgrading the runtime package and my program works.  Upgrading the waveforms package (and thus libdwf.so) causes the segfault.

Any thoughts on how I might track down where the problem is?

 

[attila]

Hi @Torfey

I didn't notice such issue with v3.7.5
Could you try v3.7.13 ? https://forum.digilentinc.com/topic/8908-waveforms-beta-download/

 

[Torfey]

Thanks @attila  With 3.7.13 still getting 

*** stack smashing detected ***: /usr/bin/python2.7 terminated
Segmentation fault
 

I put back 3.5.4 and it works.

[Torfey]

Not sure if it's useful since I don't have full code or debug symbols, but running gdb and printing the backtrace I get:

 

#0  0x00007ffff5c46688 in ?? () from /lib/x86_64-linux-gnu/libgcc_s.so.1
#1  0x00007ffff5c476f8 in _Unwind_Backtrace () from /lib/x86_64-linux-gnu/libgcc_s.so.1
#2  0x00007ffff6fe6526 in __GI___backtrace (array=<optimized out>, size=64) at ../sysdeps/x86_64/backtrace.c:109
#3  0x00007ffff6f10d62 in backtrace_and_maps (do_abort=0, do_abort@entry=2, written=false, fd=15) at ../sysdeps/unix/sysv/linux/libc_fatal.c:47
#4  0x00007ffff6f641af in __libc_message (do_abort=do_abort@entry=2, fmt=fmt@entry=0x7ffff7056cb3 "*** %s ***: %s terminated\n")
    at ../sysdeps/posix/libc_fatal.c:172
#5  0x00007ffff6fe9aa7 in __GI___fortify_fail (msg=msg@entry=0x7ffff7056c9b "stack smashing detected") at fortify_fail.c:31
#6  0x00007ffff6fe9a70 in __stack_chk_fail () at stack_chk_fail.c:28
#7  0x00007fffdbc59155 in DwfAttach() () from /usr/lib/libdwf.so
#8  0x6d7269662f736d72 in ?? ()
#9  0x2e2e2f2f65726177 in ?? ()
#10 0x642f65726168732f in ?? ()
#11 0x2f746e656c696769 in ?? ()
#12 0x6d726f6665766177 in ?? ()
#13 0x61776d7269662f73 in ?? ()
#14 0x696769642f2f6572 in ?? ()
#15 0x7661772f746e656c in ?? ()
#16 0x662f736d726f6665 in ?? ()
#17 0x2f657261776d7269 in ?? ()
#18 0x726f6c707845452f in ?? ()
#19 0x682e72746d567265 in ?? ()
#20 0x0000000000007865 in ?? ()
#21 0x0000000001595d10 in ?? ()
#22 0x00007ffff7deee38 in dl_open_worker (a=<error reading variable: Cannot access memory at address 0x6f66657661772f7c>) at dl-open.c:577
 

[attila]

Hi @Torfey

I think I managed to reproduce the issue by having very long path for the invoking application.
The DwfAttach function tries to identify if it is running in bundle mode, whether the firmware files are next to the application. This, with path longer than ~200 causes segfault.
This issue will be solved with the next WF version, >3.7.17.
Until this, if you want to use dwf >3.5.4 make sure your application is not in a deep path.

Sorry for the issue and thank you for your observation.

[Torfey]

Thanks @attila    

I'm curious though. I understand you to be talking about path length to the files on the filesystem, yes?

The executable I run has 19 chars for the python binary (/usr/bin/python2.7). It uses the standard installation libraries for debian python2.7 (/usr/lib/python2.7/dist-packages) for its import lines.

I 'cd' to the dir where my .py files are. Then run /usr/bin/python2.7 myapp.py.  The total length of the absolute path to myapp.py is 34 chars.

The libdwf.so is where the .deb file installs it, /usr/lib/libdwf.so.

So I'm not seeing an obvious place going over 200 chars, but I might be misunderstanding you. I also don't know what 'bundle mode' is, but maybe for my purposes it doesn't matter.

Is there a way I can rearrange my .py files to test whether a shorter path fixes it? I just tried moving myapp.py to a short path of /p/p/myapp.py and still get 'stack smashing'.

Cheers.

[attila]

Hi @Torfey

I only managed to reproduce the segfault when I copied the python and executed in a directory with a looong name.
So far I tried other distributions, but I will setup a Debian 8 to see how it is working on this.

[attila]

Hi @Torfey

For me with Debian 8.10 amd64 is also working fine.
If you want to try, WF v3.7.19 solves the possible path length related issue.

 

[Torfey]

Hi  @attila   

Have tried 3.7.19-2.  Seems to get past the startup trouble of 'stack smashing'. Thank you.

However, now the scope never goes from 'arm' state to 'triggered'. Exact code works with 3.5.4.  Will try some more tests to see if it's a startup timing issue.  But if you have any ideas...

Cheers.

[attila]

Hi @Torfey

The triggering should work. It is working in the example scripts and in the WF application which uses the same SDK function 

Could you post or send me your project or relevant portions from this about trigger configuration and status verification?

[attila]

Hi @Torfey

I think I found the issue...
Your application lacks the channel index argument in the following functions and only God knows what is the value of a missing argument:
dwf.FDwfDigitalOutEnableSet(self.hdwf, c_int(i), chen)
dwf.FDwfDigitalOutEnableGet(self.hdwf, c_int(i), C.byref(chen))
It took me a few hours to figure this out... It was strange that your application was working under Windows but not under Linux.

If understand correctly you are using the digital-out only to delay the analog-in acquisitions.
An easier solution would be to trigger analog-in on external trigger directly and use the trigger position to delay the capture like:
FDwfAnalogInTriggerPositionSet(hdwf, c_double(delay_in_seconds))
The trigger position is relative to middle of the capture, so if you want the trigger position relative to the left of the capture (first sample) add half buffer size
FDwfAnalogInTriggerPositionSet(hdwf, c_double(delay_in_seconds + buffer_size/sample_rate/2))

[Torfey]

Thank you very much @attila

You finding that mistake in my code, plus your path length patch, now has my code running with 3.7.19-2 on debian linux!  Very mysterious why it ever worked which, of course, makes finding the problem that much harder. (And I thought I'd gone through every single dwf call looking for discrepancies from the docs!)

I will pass along your suggestion about the trigger to my engineers. It does sound much simpler.

Cheers and thanks again!