Bug 89505 - Versant DB crashes when heap size is greater than 644MB when it addresses memory address 0x40000000.
Versant DB crashes when heap size is greater than 644MB when it addresses mem...
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
7.3
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Arjan van de Ven
Brian Brock
http://www.eidogen.com/redhat.bugzill...
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-04-23 12:25 EDT by Michael J. Ayers
Modified: 2007-04-18 12:53 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-04-23 12:35:09 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Michael J. Ayers 2003-04-23 12:25:46 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.6 (X11; Linux i686; U;) Gecko/20020916

Description of problem:
The generic error message we get when starting a Versant test database
with a heap size of greater than 644MB is:

versant@elias > startdb test
VERSANT Utility STARTDB Version 6.0.1.1.0 
Copyright (c) 1989-2002 VERSANT Corporation

Beginning physical recovery phase 

Ending physical recovery phase 

E5: VSL_SHM_ACCESS: can't access shared memory with OS err #22 (Invalid
argument)
E7034: UT_ER_SDA_INIT: Failed to initialize shared memory
versant@elias > 

When doing an strace on the above process the following calls were found
to be the problem:

shmget(IPC_PRIVATE, 4194304, IPC_CREAT|IPC_EXCL|0x180|0600) = 24150375
shmat(24150375, 0x3f800000, 0)          = 0x3f800000
shmget(IPC_PRIVATE, 4194304, IPC_CREAT|IPC_EXCL|0x180|0600) = 24183144
shmat(24183144, 0x3fc00000, 0)          = 0x3fc00000
shmget(IPC_PRIVATE, 4194304, IPC_CREAT|IPC_EXCL|0x180|0600) = 24215913
shmat(24215913, 0x40000000, 0)          = -1 EINVAL (Invalid argument)
shmctl(24215913, 0x100 /* SHM_??? */, 0) = 0
shmdt(0x3fc00000)                       = 0
shmctl(24183144, 0x100 /* SHM_??? */, 0) = 0
shmdt(0x3f800000)                       = 0
shmctl(24150375, 0x100 /* SHM_??? */, 0) = 0

It appears that it is attaching memory address space to memory
identifiers and whenever it gets to address 0x40000000 it claims invalid
argument.  We can reproduce this error every time we try it and it
always fails at the same address.  There is 2GB of memory in the system
and we are running the following kernel:

2.4.18-27.7.xsmp #1 SMP Fri Mar 14 05:52:30 EST 2003 i686 unknown

A complete strace can be found at
http://www.eidogen.com/redhat.bugzilla.txt.  If it helps this is a dual
processor 2.6 GHz Pentium 4 system with hyperthreading enabled.

Version-Release number of selected component (if applicable):
5.2.2

How reproducible:
Always

Steps to Reproduce:
1.  Change heap size for database to 645MB
2.  Start the database (startdb <dbname>
3.
    

Actual Results:  Startdb fails with the following error message.

versant@elias > startdb test
VERSANT Utility STARTDB Version 6.0.1.1.0 
Copyright (c) 1989-2002 VERSANT Corporation

Beginning physical recovery phase 

Ending physical recovery phase 

E5: VSL_SHM_ACCESS: can't access shared memory with OS err #22 (Invalid argument)
E7034: UT_ER_SDA_INIT: Failed to initialize shared memory
versant@elias >

Expected Results:  versant@elias > startdb test
VERSANT Utility STARTDB Version 6.0.1.1.0 
Copyright (c) 1989-2002 VERSANT Corporation

Beginning physical recovery phase 

Ending physical recovery phase 

Beginning logical recovery phase 

Ending logical recovery phase 

Database is in multi-user mode ...
versant@elias > 

Additional info:
Comment 1 Jakub Jelinek 2003-04-23 12:35:09 EDT
That's clearly application bug, so you should report it to the application vendor,
not us. Address 0x40000000 is TASK_UNMAPPED_BASE where kernel starts putting
mmaped memory, starting from dynamic linker, shared libraries, etc.
Trying to shmat something on top of it obviously is not the best thing to do.

Note You need to log in before you can comment on or make changes to this bug.