Hi,
I agree if you only read the C then the code looks fine, if a bit odd.
However, having looked at the coredump with gdb it seems the compiler
optomises the dereference out and passes back a pointer to the soon to
be invalid stack address rather than the value.
It only crashes with the stack pro
On Sat, 2022-12-03 at 14:35 +0100, Daniel Gröber wrote:
> Hi Scott,
>
> While mips64el was indeed fix it looks like now we have failures on
> armhf
> instead, which was working before the patch.
>
> I've patched the test driver to print some more debug output and it
> looks
> like berkeley-abc is
On Fri, 2022-12-02 at 14:04 +, Scott Ashcroft wrote:
> Hi,
>
> I agree if you only read the C then the code looks fine, if a bit
> odd.
> However, having looked at the coredump with gdb it seems the compiler
> optomises the dereference out and passes back a pointer to
Package: yosys
Version: 0.23-3
Hi,
I've done some work on why the mips64el build fails.
The issue is that the test script tests/sat/grom.ys makes yosys core in
libs/fst/fstapi.cc:fstGetUint32
Looking at the code it is clear that, when FST_DO_MISALIGNED_OPS is not
defined, an address on the stack
Hi,
I've done some work on why the mips64el build fails.
The issue is that the test script tests/sat/grom.ys makes yosys core in
libs/fst/fstapi.cc:fstGetUint32
Looking at the code it is clear that, when FST_DO_MISALIGNED_OPS is not
defined, an address on the stack is returned to calling function
Package: yosys
Version: 0.23-3
Hi,
I've done some work on why the mips64el build fails.
The issue is that the test script tests/sat/grom.ys makes yosys core in
libs/fst/fstapi.cc:fstGetUint32
Looking at the code it is clear that, when FST_DO_MISALIGNED_OPS is not
defined, an address on the stack
Hi,
I've done some work on why the mips64el build fails.
The issue is that the test script tests/sat/grom.ys makes yosys core in
libs/fst/fstapi.cc:fstGetUint32
Looking at the code it is clear that, when FST_DO_MISALIGNED_OPS is not
defined, an address on the stack is returned to calling function
Package: fpga-icestorm
Version: 0~20220102git3b7b199-1
Severity: normal
Dear Maintainer,
icetime seems to be looking in /usr/local/share/icebox and
/usr/bin/../share/icebox for chipdb files instead of
/usr/share/fpga-icestorm/chipdb.
icetime -d icebreaker.pcf -d up5k -P sg48 -mtr pcm.rpt pcm.as
Source: raspi3-firmware
Source-Version: 1.20181112-1
The contents of the package are:
# dpkg -L raspi3-firmware
/.
/etc
/etc/default
/etc/default/raspi3-firmware
/etc/initramfs
/etc/initramfs/post-update.d
/etc/initramfs/post-update.d/z50-raspi3-firmware
/etc/kernel
/etc/kernel/postinst.d
/etc/ke
Package: tomcat8
Version: 8.0.39-1
Severity: minor
Hi,
The default server.xml shipped with tomcat8 has an access log valve config as
follows:
So files are produced in /var/log/tomcat8 with filenames like:
localhost_access_log.2016-11-25.txt
However, the log rotation script /etc/cron.daily/t
Package: network-manager
Version: 1.2.0-1
Severity: normal
There seems to be some sort of problem where dhclient gets an IPv6 address but
it gets expires almost straight away.
Then since dhclient isn't running any more it doesn't get renewed.
Debug log from network manager looks like this:
May
> Could you boot a working kernel with memblock=debug on the kernel
I'm not seeing any 'memblock: Could not reserve boot range' lines.
See attached.
Tried the patch anyway and it didn't work.
Cheers,
Scott[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys
The patch makes no difference.
Is there anything else I can do to help figure this out?
Cheers,
Scott
I'm still seeing the same failure in efi_call with 4.4.4-1 and 4.5-rc4
and 4.5-rc7 from experimental on an HP x360.
It has the INSYDE Corp implementation of EFI which seems to be a common
factor.
I'll try build the kernel with the patch suggested and test that.
Cheers,
Scott
On Fri, 2015-07-10 at 19:09 +0200, Andreas Beckmann wrote:
> Control: tag -1 moreinfo
>
> Hi Scott,
>
> On Tue, 9 Oct 2012 10:57:09 +0100 (BST) Scott Ashcroft
> wrote:
> > I've got serveral milters when crash when under high load.
> > The problem seems to be
Hi,
This isn't a bug in the dhcp client but a misconfiguration of your dhcp server.
The 'DHCP Client Behavior' section of RFC3442 says, in part:
"If the DHCP server returns both a Classless Static Routes option and a Router
option, the DHCP client MUST ignore the Router option."
So you jus
Hi,
I can't reproduce this and I run a dhcp server with DHCP_INTERFACES=""
Is there anything in /var/log/daemon.log which shows why dhcpd didn't start?
Cheers,
Scott
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas
Hi,
I think the problem is that dhcp client is being killed off by
/etc/init.d/sendsigs script.
This means that it is dead by the time the nfs unmount script runs and that's
why there is no network.
I suspect that it should be making a symlink in /run/sendsigs.omit.d like
rpcbind, syslog and
Package: libmilter1.0.1
Version: 8.14.4-2.1
Severity: normal
Hi,
I've got serveral milters when crash when under high load.
The problem seems to be that a signal is caught in poll but the handler doesn't
do the right thing.
I think the problem is that the signal shouldn't fire at all.
From the
I don't believe that this a bug in freerdp but only in remmina.
If you run xfreerdp with the cliprdr plugin:
xfreerdp --plugin cliprdr
then the clipboard works correctly.
remmina appears to be loading that plugin:
grep cliprdr /proc/8389/maps
7fae695ef000-7fae695f2000 r-xp 08:02 1440
Felix Zielcke <[EMAIL PROTECTED]> wrote:
>
> Am Sonntag, den 09.11.2008, 19:11 +0000 schrieb Scott Ashcroft:
> > Package: grub-common
> > Version: 1.96+20080724-11
>> Severity: important
> >
> >
> > grub-probe misdetects the root fs
Package: grub-common
Version: 1.96+20080724-11
Severity: important
grub-probe misdetects the root fs of one of my PCs (works fine on all others).
lisa:/# grub-probe --target=fs /
fat
lisa:/# sfdisk -l /dev/sda
Disk /dev/sda: 19452 cylinders, 255 heads, 63 sectors/track
Units = cylinders of 822
22 matches
Mail list logo
