On 07/04/18 16:52, Uwe Hermann wrote:
> Hi,
> 
> On Fri, Apr 06, 2018 at 12:05:24AM +0100, Simon Kelley wrote:
>> ../../install/bin/pulseview(main+0x60e)[0x47f3be]
>> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7f301cbda830]
>> ../../install/bin/pulseview(_start+0x29)[0x480db9]
> 
> Hm, strange. This shouldn't happen, we're not aware of any bugs like
> that. Please feel free to join us on IRC (#sigrok on Freenode) for some
> more "live" debugging if possible.
> 
> What distribution and library versions are you using? 

I can reproduce with latest sigrok stable releases built on up-to-date
Ubunutu 16.04 and with your nightly AppImage on the same platform
64-bit. Using the later probably makes send by removing library version
skew.



Can you reproduce
> the problem with sigrok-cli and attach the full output of such a problematic
> run with "sigrok-cli ... -l 5"? Also a gdb backtrace of the coredump
> (if any).
> 
> Ideally, please open a bugreport with all that info at
> sigrok.org/bugzilla so we can keep track of things more easily.
> 
>  

I'll make time to do this soon. In the meantime, doing an extremely
stupid binary chop, I discovered that removing the call to
self.has_channel(2) at line 97

           if digit == 35:
                if self.has_channel(2) and fwstart is not None and
self.options['disp'] == 'fullwords':
                    self.put(fwstart, self.samplenum, self.out_ann, [3,
['%d' % fwordval]])


Seems to fix the problem. That might prompt an "of course!" moment, or
leave you even more uncertain :)


Cheers,

Simon.

>> The decoder source is available at
>>
>> http://www.thekelleys.org.uk/sigrok/pd.py
>>
>> Please excuse the quality of the code: I'm new to Python and sigrok.
>>
>>
>> Small sample files or captures run OK, but crash when exiting Pulseview,
>> larger data causes an immediate crash, I guess, looking at the
>> backtrace, because they trigger garbage collection.
>>
>> Any clues on how to get this working would be really useful.
> 
> Please make some *.sr files available for testing that can reproducibly
> lead to this issue, so that we can try to reproduce and fix the problem.
> 
> Ideally you could directly add the files to our sigrok-dumps git
> repository, we're collecting interesting sample files, e.g. for purposes
> of regression testing of protocol decoders against those, etc.
> 
> 
>> I'm happy to donate this decoder to the sigrok collection if you want
>> it, but it's specific to a 2-ton replica of a 1949 historic comuputer,
>> so I doubt anyone else will ever have a use for it :)
>>
>> http://www.tnmoc.org/special-projects/edsac
> 
> Sure, please add the decoder to the libsigrokdecode repository (let us
> know from where to pull, e.g. your github clone or such). If github is
> too much hassle, you can also send a patch or the individual files
> as well. Please add the usual license header to your *.py files as well
> before the merge, thanks!
> 
> 
> Cheers, Uwe.
> 


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
sigrok-devel mailing list
sigrok-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sigrok-devel

Reply via email to