Bug#926180: scilab: FTBFS on all - New trouble

[Alexis Murzeau]

Le 03/05/2019 à 18:39, Sylvestre Ledru a écrit :
> What about starting a xvfb during the build?
> 
> Does it fix the issue?
> 
> S
> 
> 
> Le 03/05/2019 à 16:50, Alexis Murzeau a écrit :
>> Hi,
>>
>> Indeed, I tried in a virtual machine:
>>   - install scilab
>>   - run `LANG=en_US.UTF-8 LC_ALL=C SCI_DISABLE_TK=1
>> SCI_JAVA_ENABLE_HEADLESS=1 _JAVA_OPTIONS='-Djava.awt.headless=true'
>> HOME=/tmp scilab-adv-cli -noatomsautoload -nb -l en_US -nouserstartup -e
>> "try xmltojar([],[],'en_US');catch disp(lasterror());
>> exit(-1);end;exit(0);"`
>>
>> And, while connected via ssh using Putty, I got this:
>> ```
>> [snip]
>>
>>      [6]:
>> jogamp.opengl.SharedResourceRunner.run(SharedResourceRunner.java:353)
>>      [7]: java.base/java.lang.Thread.run(Thread.java:834)
>> commons module not found.
>> graphic_objects module not found.
>> ui_data module not found.
>> graph module not found.
>> history_browser module not found.
>> slint module not found.
>> coverage module not found.
>> ```
>>
> 

Despite having *almost* the same output when calling manually the
command line outside of a build context, when I do a sbuild, I do not
have errors as x86-bm-01 have. So I think the manual run has unrelated
issues to this bug.

Actually, the build that doesn't fail (on x86-csail-02) also has the
GLException exception (search for "-- Building documentation (en_US) --"
in the logs).

The difference starts here:
```
A fatal error has been detected by Scilab.
Please check your user-defined functions (or external module ones)
should they appear in the stack trace.
Otherwise you can report a bug on http://bugzilla.scilab.org/ with:
 * a sample code which reproduces the issue
 * the result of [a, b] = getdebuginfo()
 * the following information:
[x86-bm-01:08312] Signal: Illegal instruction (4)
[x86-bm-01:08312] Signal code: Illegal operand (2)
[x86-bm-01:08312] Failing at address: 0x7ff0c87e3dcf

Call stack:
   1: 0xb2d791 <JVM_handle_linux_signal>
(/usr/lib/jvm/default-java/lib/server/libjvm.so)
   2: 0xb222b8 < >
(/usr/lib/jvm/default-java/lib/server/libjvm.so)
   3: 0x12730  < >
(/lib/x86_64-linux-gnu/libpthread.so.0)
   4: ?        ?                                (?)
End of stack

```

Where the working log has a java.lang.IllegalStateException
 exception instead. Maybe there is a memory corruption somewhere in
native code that doesn't always cause a jvm crash.

I fear the crash happen in java code, this stacktrace is not very good :(

I'm trying to run that command with valgrind, but this is very slow.

-- 
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/debian-science-maintainers/attachments/20190508/7573a17f/attachment-0001.sig>