[BRLTTY] Brlapi crashes when watching parameter

[Peter Lecky]

Hello,

It seems to be more stable with build from the web, but it seems that 
callbacks are not called.

Do i understand it well when i thing that if i register watcher e.g.

deviceModel parameter, then my watcher should be called whenewer device 
model changes? E.g. when some braille device connects via bluetooth, 
then there is a new device name? It seems that watcher is called 
immediately after registration, but not later, when there is connection 
or disconnection of braille device. Thanks for answers

On 11. 3. 2025 21:00, Peter Lecky wrote:
> Hello,
>
> I have my own build of brlapi from latest stable release. Will try to 
> use that older, which is on the web.
>
> Thank You
>
> On 11. 3. 2025 20:43, Dave Mielke wrote:
>> [quoted lines by Peter Lecky on 2025/03/11 at 12:46 +0100]
>>
>>> My code:
>>>
>>> Parameter.WatcherHandle 
>>> h=connection.getParameters().deviceModel.watch(new ParameterWatcher() {
>>>     @Override public void onParameterUpdated(int i,long l,Object o) {
>>>        U.i("parameterwatch","id:"+i);
>>>     }
>>> });
>> I just executed this code successfully, i.e. I can't reproduce the 
>> problem. I also had a quick look at the underlying code and it looks 
>> right.
>>
>>> the JNI crash:
>> [...]
>>>   k.stopka.corvus: java_vm_ext.cc:616] JNI DETECTED ERROR IN 
>>> APPLICATION:
>>> input is not valid Modified UTF-8: illegal continuation byte 0x7f
>>>   k.stopka.corvus: java_vm_ext.cc:616]     string: 'Ě>x'
>>>   k.stopka.corvus: java_vm_ext.cc:616]     input: '0xcc <0x7f> 0x3e 
>>> 0x02 0x78'
>>>   k.stopka.corvus: java_vm_ext.cc:616]     in call to NewStringUTF
>>>   k.stopka.corvus: java_vm_ext.cc:616]     from long
>>> org.a11y.brlapi.ConnectionBase.watchParameter(int, long, boolean,
>>> org.a11y.brlapi.ParameterWatcher)
>> The UTF-8 is definitely bad, i.e. 0XCC can't be followed by 0X7F.
>>
>> The "from long" makes no sense since the object for the primitive 
>> long type isn't involved.
>>
>> I'm wondering, therefore, if there might be a serious mismatch 
>> between the jar and the shared object for the JNI that you're using.
>>
-- 
Peter Lecký Stopka n. o.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://brltty.app/pipermail/brltty/attachments/20250313/626ce1c9/attachment.htm>