Some more testing:
* When run normally, or in gdb with "handle SIGSEGV nostop pass", 6.0.1
has the IllegalStateExceptions and undocumented macro warnings, 6.0.2
does not; both finish.
* valgrind --smc-check=all crashes at about the same place as this bug
(but with a segmentation fault
Some further searching suggests that Java triggers and catches SIGSEGVs
as part of normal operation, and hence is expected to not work under gdb
without "handle SIGSEGV nostop pass". With this, both 6.0.1 and 6.0.2
don't crash in gdb, i.e. the crash in gdb probably isn't this bug.
This
On Tue, 14 May 2019 00:39:07 +0200 Alexis Murzeau wrote:
> Le 13/05/2019 à 08:08, Sylvestre Ledru a écrit :
> >
> > On 12/05/2019 22:10, Julien Puydt wrote:
> >> Hi,
> >>
> >> On 12/05/2019 11:46, Alexis Murzeau wrote:
> >>
> >>> I saw that there is a bugfix release 6.0.2 with many fixes [0].
>
On 23/05/2019 22:35, Rebecca N. Palmer wrote:
It now looks like these are actually "valgrind doesn't understand Java
memory allocation"
The Valgrind documentation says --smc-check=all should fix this, but it
doesn't.
Ubuntu has a 6.0.2 package that builds in Debian, but it still has this
* valgrind: reports a _lot_ of invalid memory accesses,
It now looks like these are actually "valgrind doesn't understand Java
memory allocation" - 'valgrind jdb' and 'valgrind jar' also report large
numbers of "invalid" accesses.
However, the segfaults are still evidence that this is
Control: found -1 6.0.1-10
(I suggest opening a new bug for the 6.0.2 issues: as noted above, that
probably won't be accepted for buster even if we do get it to build.)
Running what I think is the relevant step in a debugger:
* Go to the top level directory of a _built_ source tree (i.e. one
Le 13/05/2019 à 08:08, Sylvestre Ledru a écrit :
>
> On 12/05/2019 22:10, Julien Puydt wrote:
>> Hi,
>>
>> On 12/05/2019 11:46, Alexis Murzeau wrote:
>>
>>> I saw that there is a bugfix release 6.0.2 with many fixes [0].
>> I had started to package 6.0.2 on salsa already in february. I removed
>>
Given that the error is "Illegal instruction", and reproducibly happens
on x86-bm-01 and not the other machines we've tried, could it be
something assuming CPU features more recent than the amd64 baseline?
If so, it's not obvious where: scilab does contain some C/C++ code (as
well as Java),
On 12/05/2019 22:10, Julien Puydt wrote:
> Hi,
>
> On 12/05/2019 11:46, Alexis Murzeau wrote:
>
>> I saw that there is a bugfix release 6.0.2 with many fixes [0].
> I had started to package 6.0.2 on salsa already in february. I removed
> the patch about Linenum as that was supposed to have been
Hi,
Le 12/05/2019 à 22:10, Julien Puydt a écrit :
> Hi,
>
> On 12/05/2019 11:46, Alexis Murzeau wrote:
>
>> I saw that there is a bugfix release 6.0.2 with many fixes [0].
>
> I had started to package 6.0.2 on salsa already in february.
I was wondering, will such bug-fix upstream release be
Hi,
On 12/05/2019 11:46, Alexis Murzeau wrote:
> I saw that there is a bugfix release 6.0.2 with many fixes [0].
I had started to package 6.0.2 on salsa already in february. I removed
the patch about Linenum as that was supposed to have been reworked and
fixed, and it now fails with :
ocamlopt
Le 08/05/2019 à 00:50, Alexis Murzeau a écrit :
> 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
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
Control: tags -1 moreinfo
I don't see this in a DIST=sid cowbuilder --build scilab_6.0.1-9.dsc
--binary-indep build: has it been fixed (the -8 to -9 changelog suggests
not), or does my setup allow enough graphics access to not have it?
If the bug does still exist, can someone affected try
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
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
package: src:scilab
version: 6.0.1-7
severity: serious
tags: ftbfs
Hi,
The latest version of scilab in unstable fails on all:
https://buildd.debian.org/status/logs.php?pkg=scilab=all
I don't see any relevant changes that might cause this, so I'm filing this bug
against the version in testing
17 matches
Mail list logo
