EsMappedFileMap failed to create mapping for 'ES_SHDMEM_GLOBAL_BASE_ADDRESS_0' at 0x00000000, errorCode = 0x00000005

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

EsMappedFileMap failed to create mapping for 'ES_SHDMEM_GLOBAL_BASE_ADDRESS_0' at 0x00000000, errorCode = 0x00000005

Wayne Johnston
I happened to notice this in the standard output of a headless server (VA 8.5.2) on Windows - the simpler of the two headless servers we have:

EsMappedFileMap failed to create mapping for 'ES_SHDMEM_GLOBAL_BASE_ADDRESS_0' at 0x00000000, errorCode = 0x00000005
EsMappedFileMap failed to create mapping for 'ES_SHDMEM_GLOBAL_BASE_ADDRESS_0' at 0x00000000, errorCode = 0x00000005
Failed to place FIXED memory at required address; creating PRIVATE

We always see that third line, which has been discussed before and I'm not worried about it. But what are the other two (identical) lines about?  Things work fine, so this is a curiosity question.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: EsMappedFileMap failed to create mapping for 'ES_SHDMEM_GLOBAL_BASE_ADDRESS_0' at 0x00000000, errorCode = 0x00000005

Seth Berman
Hello Wayne,

Typically, these messages can be ignored since it just means that it could not allocate a shareable segment (between images) at the desired address space.  In these cases, it goes on to create non-shared private memory.
The first 2 messages describe the 2 failed attempts to the windows CreateFileMapping API calls and I'm assuming the 3rd line gives the context in which these happened...which is...the vm was trying to allocate a fixed space segment.
The error code is actually interesting here....I'm wondering if the user you are running the process as does not have sufficient privileges to actually map global memory.  It may be interesting to try running this again with admin privileges.

-- Seth 

On Monday, May 9, 2016 at 11:21:42 AM UTC-4, Wayne Johnston wrote:
I happened to notice this in the standard output of a headless server (VA 8.5.2) on Windows - the simpler of the two headless servers we have:

EsMappedFileMap failed to create mapping for 'ES_SHDMEM_GLOBAL_BASE_ADDRESS_0' at 0x00000000, errorCode = 0x00000005
EsMappedFileMap failed to create mapping for 'ES_SHDMEM_GLOBAL_BASE_ADDRESS_0' at 0x00000000, errorCode = 0x00000005
Failed to place FIXED memory at required address; creating PRIVATE

We always see that third line, which has been discussed before and I'm not worried about it. But what are the other two (identical) lines about?  Things work fine, so this is a curiosity question.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: EsMappedFileMap failed to create mapping for 'ES_SHDMEM_GLOBAL_BASE_ADDRESS_0' at 0x00000000, errorCode = 0x00000005

Louis LaBrunda
Hi Seth,

I have also seen these messages at a customer site.  Ignoring them seems to be okay.

Can you tell me more about what the VM is trying to do.  Is it trying to allocate memory that is shared between two or more VA Smalltalk programs running on the same machine?  I do have more than one program running.  Some are NT services and some are GUI's.  I don't think I'm doing anything that needs to be shared between them.  Am I missing something?  Some of these programs communicate via TCP/IP, could I change that to some shared memory function?  Or am I imagining features that aren't there?

Lou


On Monday, May 9, 2016 at 10:09:27 PM UTC-4, Seth Berman wrote:
Hello Wayne,

Typically, these messages can be ignored since it just means that it could not allocate a shareable segment (between images) at the desired address space.  In these cases, it goes on to create non-shared private memory.
The first 2 messages describe the 2 failed attempts to the windows CreateFileMapping API calls and I'm assuming the 3rd line gives the context in which these happened...which is...the vm was trying to allocate a fixed space segment.
The error code is actually interesting here....I'm wondering if the user you are running the process as does not have sufficient privileges to actually map global memory.  It may be interesting to try running this again with admin privileges.

-- Seth 

On Monday, May 9, 2016 at 11:21:42 AM UTC-4, Wayne Johnston wrote:
I happened to notice this in the standard output of a headless server (VA 8.5.2) on Windows - the simpler of the two headless servers we have:

EsMappedFileMap failed to create mapping for 'ES_SHDMEM_GLOBAL_BASE_ADDRESS_0' at 0x00000000, errorCode = 0x00000005
EsMappedFileMap failed to create mapping for 'ES_SHDMEM_GLOBAL_BASE_ADDRESS_0' at 0x00000000, errorCode = 0x00000005
Failed to place FIXED memory at required address; creating PRIVATE

We always see that third line, which has been discussed before and I'm not worried about it. But what are the other two (identical) lines about?  Things work fine, so this is a curiosity question.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: EsMappedFileMap failed to create mapping for 'ES_SHDMEM_GLOBAL_BASE_ADDRESS_0' at 0x00000000, errorCode = 0x00000005

Seth Berman
Hi Lou,

This is one of my least favorite "features" of the vm because it results in a tremendous amount of complexity to support what I often just disable anyway (-msd).

It's trying to share read-only smalltalk segments (like ICs) using the file memory mapping capabilities of the OS.  It can "very roughly" be thought of as a non-relocatable smalltalk dll implementation.
The non-relocatable aspect is what results in these messages, which look severe, but basically are just saying "I can't map this smalltalk segment full of code/symobls whatever to this exact specified address space for reason X, where X is often that it is occupied by something else.
This isn't a problem, because then it just says, "Oh well, I'll just create my own private non-shared version in this other location and be done with it".  Or, you can do what I do, which is just provide the -msd switch and it always creates non-shareable segments anyway.

The concept of "shareable smalltalk memory" doesn't bother me to much...I can certainly think of some situations where this could be useful...though it's utility today is probably less than what it was once upon a time.  Mostly I don't like it because it shows up in just about every other part of the vm like the memory manager, packager, bytecodes, primitives.  It's always there adding additional complexity to what should be fairly straightforward.

But this is purely a maintainer's gripe...perhaps there are others out there who take advantage of this facility and can describe how this mechanism gave them some sort of edge.
Somehow, knowing this is the case for at least 1 person would make me feel better:)

-- Seth

On Tuesday, May 10, 2016 at 8:05:39 AM UTC-4, Louis LaBrunda wrote:
Hi Seth,

I have also seen these messages at a customer site.  Ignoring them seems to be okay.

Can you tell me more about what the VM is trying to do.  Is it trying to allocate memory that is shared between two or more VA Smalltalk programs running on the same machine?  I do have more than one program running.  Some are NT services and some are GUI's.  I don't think I'm doing anything that needs to be shared between them.  Am I missing something?  Some of these programs communicate via TCP/IP, could I change that to some shared memory function?  Or am I imagining features that aren't there?

Lou


On Monday, May 9, 2016 at 10:09:27 PM UTC-4, Seth Berman wrote:
Hello Wayne,

Typically, these messages can be ignored since it just means that it could not allocate a shareable segment (between images) at the desired address space.  In these cases, it goes on to create non-shared private memory.
The first 2 messages describe the 2 failed attempts to the windows CreateFileMapping API calls and I'm assuming the 3rd line gives the context in which these happened...which is...the vm was trying to allocate a fixed space segment.
The error code is actually interesting here....I'm wondering if the user you are running the process as does not have sufficient privileges to actually map global memory.  It may be interesting to try running this again with admin privileges.

-- Seth 

On Monday, May 9, 2016 at 11:21:42 AM UTC-4, Wayne Johnston wrote:
I happened to notice this in the standard output of a headless server (VA 8.5.2) on Windows - the simpler of the two headless servers we have:

EsMappedFileMap failed to create mapping for 'ES_SHDMEM_GLOBAL_BASE_ADDRESS_0' at 0x00000000, errorCode = 0x00000005
EsMappedFileMap failed to create mapping for 'ES_SHDMEM_GLOBAL_BASE_ADDRESS_0' at 0x00000000, errorCode = 0x00000005
Failed to place FIXED memory at required address; creating PRIVATE

We always see that third line, which has been discussed before and I'm not worried about it. But what are the other two (identical) lines about?  Things work fine, so this is a curiosity question.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: EsMappedFileMap failed to create mapping for 'ES_SHDMEM_GLOBAL_BASE_ADDRESS_0' at 0x00000000, errorCode = 0x00000005

Louis LaBrunda
Hi Seth,

Thanks for the reply.  I don't use ICs, so I'm going to start using the -msd switch.  We all like backward compatibility but maybe it is a good time to see if ICs or anything that needs to share read-only smalltalk segments is worth the effort to support them in the new 32/64 bit VMs.  Or maybe don't worry about sharing them and just put them in non-shared space if that makes the VM simpler.

Also, can't the VM tell if anything in the image is asking for shared space or not before it tried to obtain it?  Or are Wayne and I (at lease me) doing something that needs shared space and we don't even know it?

Lou

On Tuesday, May 10, 2016 at 10:16:11 AM UTC-4, Seth Berman wrote:
Hi Lou,

This is one of my least favorite "features" of the vm because it results in a tremendous amount of complexity to support what I often just disable anyway (-msd).

It's trying to share read-only smalltalk segments (like ICs) using the file memory mapping capabilities of the OS.  It can "very roughly" be thought of as a non-relocatable smalltalk dll implementation.
The non-relocatable aspect is what results in these messages, which look severe, but basically are just saying "I can't map this smalltalk segment full of code/symobls whatever to this exact specified address space for reason X, where X is often that it is occupied by something else.
This isn't a problem, because then it just says, "Oh well, I'll just create my own private non-shared version in this other location and be done with it".  Or, you can do what I do, which is just provide the -msd switch and it always creates non-shareable segments anyway.

The concept of "shareable smalltalk memory" doesn't bother me to much...I can certainly think of some situations where this could be useful...though it's utility today is probably less than what it was once upon a time.  Mostly I don't like it because it shows up in just about every other part of the vm like the memory manager, packager, bytecodes, primitives.  It's always there adding additional complexity to what should be fairly straightforward.

But this is purely a maintainer's gripe...perhaps there are others out there who take advantage of this facility and can describe how this mechanism gave them some sort of edge.
Somehow, knowing this is the case for at least 1 person would make me feel better:)

-- Seth

On Tuesday, May 10, 2016 at 8:05:39 AM UTC-4, Louis LaBrunda wrote:
Hi Seth,

I have also seen these messages at a customer site.  Ignoring them seems to be okay.

Can you tell me more about what the VM is trying to do.  Is it trying to allocate memory that is shared between two or more VA Smalltalk programs running on the same machine?  I do have more than one program running.  Some are NT services and some are GUI's.  I don't think I'm doing anything that needs to be shared between them.  Am I missing something?  Some of these programs communicate via TCP/IP, could I change that to some shared memory function?  Or am I imagining features that aren't there?

Lou


On Monday, May 9, 2016 at 10:09:27 PM UTC-4, Seth Berman wrote:
Hello Wayne,

Typically, these messages can be ignored since it just means that it could not allocate a shareable segment (between images) at the desired address space.  In these cases, it goes on to create non-shared private memory.
The first 2 messages describe the 2 failed attempts to the windows CreateFileMapping API calls and I'm assuming the 3rd line gives the context in which these happened...which is...the vm was trying to allocate a fixed space segment.
The error code is actually interesting here....I'm wondering if the user you are running the process as does not have sufficient privileges to actually map global memory.  It may be interesting to try running this again with admin privileges.

-- Seth 

On Monday, May 9, 2016 at 11:21:42 AM UTC-4, Wayne Johnston wrote:
I happened to notice this in the standard output of a headless server (VA 8.5.2) on Windows - the simpler of the two headless servers we have:

EsMappedFileMap failed to create mapping for 'ES_SHDMEM_GLOBAL_BASE_ADDRESS_0' at 0x00000000, errorCode = 0x00000005
EsMappedFileMap failed to create mapping for 'ES_SHDMEM_GLOBAL_BASE_ADDRESS_0' at 0x00000000, errorCode = 0x00000005
Failed to place FIXED memory at required address; creating PRIVATE

We always see that third line, which has been discussed before and I'm not worried about it. But what are the other two (identical) lines about?  Things work fine, so this is a curiosity question.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: EsMappedFileMap failed to create mapping for 'ES_SHDMEM_GLOBAL_BASE_ADDRESS_0' at 0x00000000, errorCode = 0x00000005

Seth Berman
Hi Lou,

"I don't use ICs"
- Perhaps you mean you don't use IC packaging.  If you ever launched VA Smalltalk...then you use ICs.  You can see these in the <VA_INSTALL_ROOT>/8.6/icsrn8xx directory.

"...worth the effort to support"
- Ripping them out will break....EVERYTHING

"...don't worry about sharing them"
-msd accomplishes this and perhaps it should be the default.  It doesn't make the vm any simpler since the code must remain...but it gets rid of worrisome messages in a log file.

"..can't the VM tell if anything in the image is asking for shared space..."
- No, it doesn't work like that.  The packager gets involved and does magic to replace what goes into ICs...this implicitly calls on different behavior during vm execution.

-- Seth

On Tuesday, May 10, 2016 at 11:24:49 AM UTC-4, Louis LaBrunda wrote:
Hi Seth,

Thanks for the reply.  I don't use ICs, so I'm going to start using the -msd switch.  We all like backward compatibility but maybe it is a good time to see if ICs or anything that needs to share read-only smalltalk segments is worth the effort to support them in the new 32/64 bit VMs.  Or maybe don't worry about sharing them and just put them in non-shared space if that makes the VM simpler.

Also, can't the VM tell if anything in the image is asking for shared space or not before it tried to obtain it?  Or are Wayne and I (at lease me) doing something that needs shared space and we don't even know it?

Lou

On Tuesday, May 10, 2016 at 10:16:11 AM UTC-4, Seth Berman wrote:
Hi Lou,

This is one of my least favorite "features" of the vm because it results in a tremendous amount of complexity to support what I often just disable anyway (-msd).

It's trying to share read-only smalltalk segments (like ICs) using the file memory mapping capabilities of the OS.  It can "very roughly" be thought of as a non-relocatable smalltalk dll implementation.
The non-relocatable aspect is what results in these messages, which look severe, but basically are just saying "I can't map this smalltalk segment full of code/symobls whatever to this exact specified address space for reason X, where X is often that it is occupied by something else.
This isn't a problem, because then it just says, "Oh well, I'll just create my own private non-shared version in this other location and be done with it".  Or, you can do what I do, which is just provide the -msd switch and it always creates non-shareable segments anyway.

The concept of "shareable smalltalk memory" doesn't bother me to much...I can certainly think of some situations where this could be useful...though it's utility today is probably less than what it was once upon a time.  Mostly I don't like it because it shows up in just about every other part of the vm like the memory manager, packager, bytecodes, primitives.  It's always there adding additional complexity to what should be fairly straightforward.

But this is purely a maintainer's gripe...perhaps there are others out there who take advantage of this facility and can describe how this mechanism gave them some sort of edge.
Somehow, knowing this is the case for at least 1 person would make me feel better:)

-- Seth

On Tuesday, May 10, 2016 at 8:05:39 AM UTC-4, Louis LaBrunda wrote:
Hi Seth,

I have also seen these messages at a customer site.  Ignoring them seems to be okay.

Can you tell me more about what the VM is trying to do.  Is it trying to allocate memory that is shared between two or more VA Smalltalk programs running on the same machine?  I do have more than one program running.  Some are NT services and some are GUI's.  I don't think I'm doing anything that needs to be shared between them.  Am I missing something?  Some of these programs communicate via TCP/IP, could I change that to some shared memory function?  Or am I imagining features that aren't there?

Lou


On Monday, May 9, 2016 at 10:09:27 PM UTC-4, Seth Berman wrote:
Hello Wayne,

Typically, these messages can be ignored since it just means that it could not allocate a shareable segment (between images) at the desired address space.  In these cases, it goes on to create non-shared private memory.
The first 2 messages describe the 2 failed attempts to the windows CreateFileMapping API calls and I'm assuming the 3rd line gives the context in which these happened...which is...the vm was trying to allocate a fixed space segment.
The error code is actually interesting here....I'm wondering if the user you are running the process as does not have sufficient privileges to actually map global memory.  It may be interesting to try running this again with admin privileges.

-- Seth 

On Monday, May 9, 2016 at 11:21:42 AM UTC-4, Wayne Johnston wrote:
I happened to notice this in the standard output of a headless server (VA 8.5.2) on Windows - the simpler of the two headless servers we have:

EsMappedFileMap failed to create mapping for 'ES_SHDMEM_GLOBAL_BASE_ADDRESS_0' at 0x00000000, errorCode = 0x00000005
EsMappedFileMap failed to create mapping for 'ES_SHDMEM_GLOBAL_BASE_ADDRESS_0' at 0x00000000, errorCode = 0x00000005
Failed to place FIXED memory at required address; creating PRIVATE

We always see that third line, which has been discussed before and I'm not worried about it. But what are the other two (identical) lines about?  Things work fine, so this is a curiosity question.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: EsMappedFileMap failed to create mapping for 'ES_SHDMEM_GLOBAL_BASE_ADDRESS_0' at 0x00000000, errorCode = 0x00000005

Louis LaBrunda
Hey Seth,

On Tuesday, May 10, 2016 at 12:04:09 PM UTC-4, Seth Berman wrote:
Hi Lou,

"I don't use ICs"
- Perhaps you mean you don't use IC packaging.  If you ever launched VA Smalltalk...then you use ICs.  You can see these in the <VA_INSTALL_ROOT>/8.6/icsrn8xx directory.

You are correct, I don't use IC packaging.  I see, so the development environment uses them like crazy.
 
"...worth the effort to support"
- Ripping them out will break....EVERYTHING

Got it.
 
"...don't worry about sharing them"
-msd accomplishes this and perhaps it should be the default.  It doesn't make the vm any simpler since the code must remain...but it gets rid of worrisome messages in a log file.

If like 90% of our packaged images don't need the shared memory, making -msd the default might be a good idea.
 
"..can't the VM tell if anything in the image is asking for shared space..."
- No, it doesn't work like that.  The packager gets involved and does magic to replace what goes into ICs...this implicitly calls on different behavior during vm execution.

Got it.

Lou
 
-- Seth

On Tuesday, May 10, 2016 at 11:24:49 AM UTC-4, Louis LaBrunda wrote:
Hi Seth,

Thanks for the reply.  I don't use ICs, so I'm going to start using the -msd switch.  We all like backward compatibility but maybe it is a good time to see if ICs or anything that needs to share read-only smalltalk segments is worth the effort to support them in the new 32/64 bit VMs.  Or maybe don't worry about sharing them and just put them in non-shared space if that makes the VM simpler.

Also, can't the VM tell if anything in the image is asking for shared space or not before it tried to obtain it?  Or are Wayne and I (at lease me) doing something that needs shared space and we don't even know it?

Lou

On Tuesday, May 10, 2016 at 10:16:11 AM UTC-4, Seth Berman wrote:
Hi Lou,

This is one of my least favorite "features" of the vm because it results in a tremendous amount of complexity to support what I often just disable anyway (-msd).

It's trying to share read-only smalltalk segments (like ICs) using the file memory mapping capabilities of the OS.  It can "very roughly" be thought of as a non-relocatable smalltalk dll implementation.
The non-relocatable aspect is what results in these messages, which look severe, but basically are just saying "I can't map this smalltalk segment full of code/symobls whatever to this exact specified address space for reason X, where X is often that it is occupied by something else.
This isn't a problem, because then it just says, "Oh well, I'll just create my own private non-shared version in this other location and be done with it".  Or, you can do what I do, which is just provide the -msd switch and it always creates non-shareable segments anyway.

The concept of "shareable smalltalk memory" doesn't bother me to much...I can certainly think of some situations where this could be useful...though it's utility today is probably less than what it was once upon a time.  Mostly I don't like it because it shows up in just about every other part of the vm like the memory manager, packager, bytecodes, primitives.  It's always there adding additional complexity to what should be fairly straightforward.

But this is purely a maintainer's gripe...perhaps there are others out there who take advantage of this facility and can describe how this mechanism gave them some sort of edge.
Somehow, knowing this is the case for at least 1 person would make me feel better:)

-- Seth

On Tuesday, May 10, 2016 at 8:05:39 AM UTC-4, Louis LaBrunda wrote:
Hi Seth,

I have also seen these messages at a customer site.  Ignoring them seems to be okay.

Can you tell me more about what the VM is trying to do.  Is it trying to allocate memory that is shared between two or more VA Smalltalk programs running on the same machine?  I do have more than one program running.  Some are NT services and some are GUI's.  I don't think I'm doing anything that needs to be shared between them.  Am I missing something?  Some of these programs communicate via TCP/IP, could I change that to some shared memory function?  Or am I imagining features that aren't there?

Lou


On Monday, May 9, 2016 at 10:09:27 PM UTC-4, Seth Berman wrote:
Hello Wayne,

Typically, these messages can be ignored since it just means that it could not allocate a shareable segment (between images) at the desired address space.  In these cases, it goes on to create non-shared private memory.
The first 2 messages describe the 2 failed attempts to the windows CreateFileMapping API calls and I'm assuming the 3rd line gives the context in which these happened...which is...the vm was trying to allocate a fixed space segment.
The error code is actually interesting here....I'm wondering if the user you are running the process as does not have sufficient privileges to actually map global memory.  It may be interesting to try running this again with admin privileges.

-- Seth 

On Monday, May 9, 2016 at 11:21:42 AM UTC-4, Wayne Johnston wrote:
I happened to notice this in the standard output of a headless server (VA 8.5.2) on Windows - the simpler of the two headless servers we have:

EsMappedFileMap failed to create mapping for 'ES_SHDMEM_GLOBAL_BASE_ADDRESS_0' at 0x00000000, errorCode = 0x00000005
EsMappedFileMap failed to create mapping for 'ES_SHDMEM_GLOBAL_BASE_ADDRESS_0' at 0x00000000, errorCode = 0x00000005
Failed to place FIXED memory at required address; creating PRIVATE

We always see that third line, which has been discussed before and I'm not worried about it. But what are the other two (identical) lines about?  Things work fine, so this is a curiosity question.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.