Hi Waldek,
Our tree is up to date with f7b6bee552b41f56a55, plus I manually
applied your patch from this thread (as at the time it wasn't
committed).
Error seems to happen regardless of memory size I specify - but we
can't go below 2GB for memory reasons (btw - we seem to just freeze
when we run
On Thu, 2019-08-22 at 21:49 +1100, Rick Payne wrote:
> On Thu, 2019-08-22 at 12:30 +0300, Nadav Har'El wrote:
>
> > Please run "osv syms" to allow gdb to find your application object
> > files, and show lines there. Perhaps it's a segfault inside your
> > application, not the kernel?
>
> I had,
On Thu, 2019-08-22 at 12:30 +0300, Nadav Har'El wrote:
> Please run "osv syms" to allow gdb to find your application object
> files, and show lines there. Perhaps it's a segfault inside your
> application, not the kernel?
I had, but I had forgotten to add our stuff to the usr.manifest so the
On Thu, 2019-08-22 at 10:33 +0300, Nadav Har'El wrote:
> You're right, it seems there's should be a "return" in the recursive
> case!
> That being said, I think the spurious wakeup doesn't cause any harm,
> because the wait code rwlock::writer_wait_lockable() loops, and if a
> thread
> is woken
On Thu, 2019-08-22 at 10:47 +0300, Nadav Har'El wrote:
> Do you know how to get a backtrace from gdb?
Yes, see below. It wasn't running out of memory:
(gdb) osv mem
Total Memory: 8589392896 Bytes
Mmap Memory: 2231259136 Bytes (25.98%)
Free Memory: 7464316928 Bytes (86.90%)
This is the most
On Thu, Aug 22, 2019 at 9:53 AM Rick Payne wrote:
> On Wed, 2019-08-21 at 13:21 +0300, Nadav Har'El wrote:
> >
> > This is often not the problem itself, but rather a result of an
> > earlier bug, which caused
> > us to want to print an error message and that generated another
> > error, and so
On Wed, Aug 21, 2019 at 10:21 PM Rick Payne wrote:
> On Wed, 2019-08-21 at 12:22 +0300, Nadav Har'El wrote:
> > I am guessing (need to verify...) that our rwlock implementation is
> > not recursive - a thread already holding the write lock needs to wait
> > (forever) for the read lock. If this
On Wed, 2019-08-21 at 13:21 +0300, Nadav Har'El wrote:
>
> This is often not the problem itself, but rather a result of an
> earlier bug, which caused
> us to want to print an error message and that generated another
> error, and so on.
Understood.
Still working on testing 0.53, and I'm now
On Wednesday, August 21, 2019 at 5:22:19 AM UTC-4, Nadav Har'El wrote:
>
> On Wed, Aug 21, 2019 at 6:04 AM Waldek Kozaczuk > wrote:
>
>> This patch definitely fixes an apparent bug I introduced myself in the
>> past. I have tested that issue #1048 goes away with 4,5,6, 7 or 8GB of
>> memory.
On Wed, 2019-08-21 at 12:22 +0300, Nadav Har'El wrote:
> I am guessing (need to verify...) that our rwlock implementation is
> not recursive - a thread already holding the write lock needs to wait
> (forever) for the read lock. If this is true, this is an rwlock bug.
So I was puzzled a bit by the
On Wed, Aug 21, 2019 at 2:21 PM Waldek Kozaczuk
wrote:
> Hi,
>
> Thanks for committing this patch. But unfortunately the tst-huge.so
> problem is going to make the unit tests fails.
>
As bad this is, better one unit failing than a lot of real use cases (which
unfortunately none of the unit
Hi,
Thanks for committing this patch. But unfortunately the tst-huge.so problem is
going to make the unit tests fails.
I saw you opened the issue about it. Shall we disable the test until we fix it
or somehow change setup and make this test run with 1GB memory instead?
Waldek
--
You
On Wed, Aug 21, 2019 at 10:09 AM Rick Payne wrote:
>
> Thanks for this - I was hitting a wierd page fault issue on our
> application as we've recently moved from 0.52 to the latest OSv.
> Something like this, which occurs early on in startup:
>
> Assertion failed: ef->rflags &
On Wed, Aug 21, 2019 at 6:04 AM Waldek Kozaczuk
wrote:
> This patch definitely fixes an apparent bug I introduced myself in the
> past. I have tested that issue #1048 goes away with 4,5,6, 7 or 8GB of
> memory. I have also verified using cli module that free memory is reported
> properly now.
>
Thanks for this - I was hitting a wierd page fault issue on our
application as we've recently moved from 0.52 to the latest OSv.
Something like this, which occurs early on in startup:
Assertion failed: ef->rflags & processor::rflags_if (arch/x64/mmu.cc:
page_fault: 34)
[backtrace]
This patch definitely fixes an apparent bug I introduced myself in the
past. I have tested that issue #1048 goes away with 4,5,6, 7 or 8GB of
memory. I have also verified using cli module that free memory is reported
properly now.
However, there is still 1 question and 1 issue outstanding:
1.
16 matches
Mail list logo
