This is an automatically generated notice of a NetBSD-current/i386
build failure.
The failure occurred on babylon5.netbsd.org, a NetBSD/amd64 host,
using sources from CVS date 2020.06.30.00.26.12.
An extract from the build.sh output follows:
cat
> On Jun 29, 2020, at 5:13 PM, Kamil Rytarowski wrote:
>
>>
>> The atexit() function shall register the function pointed to by func, to be
>> called without arguments at normal program termination. At normal program
>> termination, all functions registered by the atexit() function shall be
Updating src tree:
P src/distrib/sets/lists/debug/mi
P src/distrib/sets/lists/tests/mi
P src/doc/CHANGES
P src/external/bsd/kyua-cli/tests/kyua-cli/bootstrap/Makefile
P src/external/bsd/kyua-cli/tests/kyua-cli/cli/Makefile
P src/external/bsd/kyua-cli/tests/kyua-cli/engine/Makefile
P
On 29.06.2020 21:36, Jason Thorpe wrote:
>
>> On Jun 29, 2020, at 9:09 AM, Rhialto wrote:
>>
>> But I wonder if there is any standards text that
>> describes whether this particular scenario is supposed to work.
>
> Quoting from "The Open Group Base Specifications Issue 7, 2018 edition"
>
>
>
FWIW I just rebuilt it on today's -current amd64 and -current pkgsrc;
it wasn't rebuilt during the last rolling-replace, so the package was
from early May; today it was also built right away.
I've had various troubles in the past building this package; at one
stage it would not build unless
I wrote:
>What is wrong with the idea that you have run out of memory ?
OTOH, running top(1) at the same time as building it doesn't show
any particularly large processes.
On Mon, Jun 29, 2020 at 11:43:55PM +0200, Riccardo Mottola wrote:
> Hi Maya!
>
> m...@netbsd.org wrote:
> > > > distutils.errors.CompileError: command 'cpp' terminated by signal 11
> > > Usually any GCC crashes on widely used architectures are running out of
> > > RAM.
> > See `dmesg |tail` to
Riccardo Mottola wrote:
>m...@netbsd.org wrote:
distutils.errors.CompileError: command 'cpp' terminated by signal 11
>>> Usually any GCC crashes on widely used architectures are running out of
>>> RAM.
>> See `dmesg |tail` to see some messages related to out-of-RAM GCC
>> components
Hi Maya!
m...@netbsd.org wrote:
distutils.errors.CompileError: command 'cpp' terminated by signal 11
Usually any GCC crashes on widely used architectures are running out of
RAM.
See `dmesg |tail` to see some messages related to out-of-RAM GCC
components killed.
dmesg does not report
> On Jun 29, 2020, at 9:09 AM, Rhialto wrote:
>
> But I wonder if there is any standards text that
> describes whether this particular scenario is supposed to work.
Quoting from "The Open Group Base Specifications Issue 7, 2018 edition"
The atexit() function shall register the function
I made a small program reproducing the problem, also with a base system
library. I randomly chose /usr/lib/libtermcap.so as default, but I think
everything that turns up by grep _fini /usr/lib/*.so will do.
Actual output:
$ ./dl
main thread 0x706e490a2800: calling exit()
main thread
On Mon, Jun 29, 2020 at 12:53:23PM +0900, Kengo NAKAHARA wrote:
> It seems some other code have held KERNEL_LOCK too long time.
> Could you show the function of last locked address?
> # e.g. addr2line -e "your kernel image" -f 0x80a7d2f5
With Jun 28 14:26 code
# addr2line -e netbsd.3.gdb
On Mon 29 Jun 2020 at 09:55:10 +0200, Rhialto wrote:
> I've looked at __cxa_finalize a bit better, and it seems that the lock
> mutex_lock(&__atexit_mutex); isn't just used to protect running the
> atexit handlers, but even to protect looking at the list of handlers:
> atexit_handler_stack.
> So
On Mon 29 Jun 2020 at 10:39:45 +0200, Martin Husemann wrote:
> On Mon, Jun 29, 2020 at 09:55:10AM +0200, Rhialto wrote:
> > 6. said handler tells the new thread to clean up and finish. One of the last
> >things the thread does, is to dlclose() libavformat.
>
> How can an atexit() handler (or
On Mon, Jun 29, 2020 at 04:02:43PM +, m...@netbsd.org wrote:
> On Mon, Jun 29, 2020 at 12:32:27PM +0200, Riccardo Mottola wrote:
> > distutils.errors.CompileError: command 'cpp' terminated by signal 11
>
> Usually any GCC crashes on widely used architectures are running out of
> RAM.
See
On Mon, Jun 29, 2020 at 12:32:27PM +0200, Riccardo Mottola wrote:
> distutils.errors.CompileError: command 'cpp' terminated by signal 11
Usually any GCC crashes on widely used architectures are running out of
RAM.
On Sun 28 Jun 2020 at 23:29:05 +0200, Joerg Sonnenberger wrote:
> On Sun, Jun 28, 2020 at 10:56:01PM +0200, Rhialto wrote:
> > The funny thing is that libavformat uses an atexit handler due to issues
> > with dynamic (un)loading (or so they claim). This is from their file
> >
17 matches
Mail list logo
