Re: second call to mmap() results in error

2014-01-30 Thread Larry Hall (Cygwin)
On 1/30/2014 2:46 PM, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote: OP privately wrote: The problem is also fixed by correct type-casting in the calls to mmap() ... mmap1 = mmap(NULL, (size_t) 524304, PROT_WRITE | PROT_READ, MAP_SHARED, shm_fd1, 0); The address returned from the call to mmap

RE: second call to mmap() results in error

2014-01-30 Thread Lavrentiev, Anton (NIH/NLM/NCBI) [C]
> So if the question is why do you need to include ftruncate() in the code, > take a look here: No, that was not the question. W/o ftruncate(), _referencing_ the memory becomes a problem (and the original code did not do that, but simply mmap'ed two files). > > Adding the fixes the problem in a

Re: second call to mmap() results in error

2014-01-30 Thread Larry Hall (Cygwin)
On 1/30/2014 2:04 PM, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote: Forget mmap(). Why? The response was: Adding the fixes the problem in all its iterations -- the original mmap() test works (without the call to ftruncate()), as well as the second one. Note *the original*.

RE: second call to mmap() results in error

2014-01-30 Thread Lavrentiev, Anton (NIH/NLM/NCBI) [C]
> Forget mmap(). Why? The response was: > Adding the fixes the problem in all its iterations -- the original > mmap() > test works (without the call to ftruncate()), as well as the second one. Note *the original*. Anton Lavrentiev Contractor NIH/NLM/NCBI -- Problem reports: http://c

Re: second call to mmap() results in error

2014-01-30 Thread Larry Hall (Cygwin)
On 1/30/2014 1:52 PM, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote: Try adding -Wall to your compile line. I did. There was no warning (and it should not have because #include is there). Why ? It's not needed to compile and run the original code. Forget mmap(). That's not the issue here.

RE: second call to mmap() results in error

2014-01-30 Thread Lavrentiev, Anton (NIH/NLM/NCBI) [C]
> Try adding -Wall to your compile line. I did. There was no warning (and it should not have because #include is there). Why ? It's not needed to compile and run the original code. Anton Lavrentiev Contractor NIH/NLM/NCBI -- Problem reports: http://cygwin.com/problems.html FAQ:

Re: second call to mmap() results in error

2014-01-30 Thread Larry Hall (Cygwin)
On 1/30/2014 1:44 PM, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote: #if*n*def __INSIDE_CYGWIN__ Alright, I can't read, sorry. Still, I can't figure out why adding has fixed the initial program made it run successfully (as the OP reported). Try adding -Wall to your compile line. -- Larry ___

RE: second call to mmap() results in error

2014-01-30 Thread Lavrentiev, Anton (NIH/NLM/NCBI) [C]
> #if*n*def __INSIDE_CYGWIN__ Alright, I can't read, sorry. Still, I can't figure out why adding has fixed the initial program made it run successfully (as the OP reported). Anton Lavrentiev Contractor NIH/NLM/NCBI -- Problem reports: http://cygwin.com/problems.html FAQ:

Re: second call to mmap() results in error

2014-01-30 Thread Christopher Faylor
On Thu, Jan 30, 2014 at 06:36:34PM +, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote: >> Maybe you missed Corinna's reply? >> >> > >No, I did not. She was going after ftruncate() there. > >Yet, the problem seems to be in cygwin's , which does t

RE: second call to mmap() results in error

2014-01-30 Thread Lavrentiev, Anton (NIH/NLM/NCBI) [C]
> Maybe you missed Corinna's reply? > > No, I did not. She was going after ftruncate() there. Yet, the problem seems to be in cygwin's , which does this: #ifndef __INSIDE_CYGWIN__ extern void *mmap (void *__addr, size_t __len, int __prot, int

Re: second call to mmap() results in error

2014-01-30 Thread Larry Hall (Cygwin)
On 1/30/2014 12:24 PM, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote: Adding the fixes the problem in all its iterations I must be missing a point here, so what was the problem with the original test program (which BTW worked fine on my CYGWIN installation). Seems like was not needed there? An

RE: second call to mmap() results in error

2014-01-30 Thread Lavrentiev, Anton (NIH/NLM/NCBI) [C]
> Adding the fixes the problem in all its iterations I must be missing a point here, so what was the problem with the original test program (which BTW worked fine on my CYGWIN installation). Seems like was not needed there? And how adding just (w/o adding ftruncate(), IIUC) has made it work?

Re: second call to mmap() results in error

2014-01-30 Thread Corinna Vinschen
On Jan 30 08:19, Steven Bardwell wrote: > > On Jan 30 07:25, Steven Bardwell wrote: > > > > > On 29/01/2014 19:12, Corinna Vinschen wrote: > > > > > >On Jan 29 09:00, Steven Bardwell wrote: > > > > > >>My application needs several areas of shared memory, and I am > > getting > > > > an > > > > > >>

RE: second call to mmap() results in error

2014-01-30 Thread Steven Bardwell
> On Jan 30 07:25, Steven Bardwell wrote: > > > > On 29/01/2014 19:12, Corinna Vinschen wrote: > > > > >On Jan 29 09:00, Steven Bardwell wrote: > > > > >>My application needs several areas of shared memory, and I am > getting > > > an > > > > >>error ("No such device") on the second call to mmap().

Re: second call to mmap() results in error

2014-01-30 Thread Corinna Vinschen
On Jan 30 07:25, Steven Bardwell wrote: > > > On 29/01/2014 19:12, Corinna Vinschen wrote: > > > >On Jan 29 09:00, Steven Bardwell wrote: > > > >>My application needs several areas of shared memory, and I am getting > > an > > > >>error ("No such device") on the second call to mmap(). The first cal

RE: second call to mmap() results in error

2014-01-30 Thread Steven Bardwell
> > On 29/01/2014 19:12, Corinna Vinschen wrote: > > >On Jan 29 09:00, Steven Bardwell wrote: > > >>My application needs several areas of shared memory, and I am getting > an > > >>error ("No such device") on the second call to mmap(). The first call > works > > >>fine. > > Sorry guys, but it stil

Re: second call to mmap() results in error

2014-01-30 Thread Corinna Vinschen
On Jan 29 20:33, Marco Atzeri wrote: > > > On 29/01/2014 19:12, Corinna Vinschen wrote: > >On Jan 29 09:00, Steven Bardwell wrote: > >>My application needs several areas of shared memory, and I am getting an > >>error ("No such device") on the second call to mmap(). The first call works > >>fine.

Re: second call to mmap() results in error

2014-01-29 Thread Marco Atzeri
On 29/01/2014 19:12, Corinna Vinschen wrote: On Jan 29 09:00, Steven Bardwell wrote: My application needs several areas of shared memory, and I am getting an error ("No such device") on the second call to mmap(). The first call works fine. The problem does not seem to depend on the size o

RE: second call to mmap() results in error

2014-01-29 Thread Steven Bardwell
> On Jan 29 09:00, Steven Bardwell wrote: > > My application needs several areas of shared memory, and I am getting an > > error ("No such device") on the second call to mmap(). The first call works > > fine. > > > > > > The problem does not seem to depend on the size of the requested > > memory.

Re: second call to mmap() results in error

2014-01-29 Thread Corinna Vinschen
On Jan 29 09:00, Steven Bardwell wrote: > My application needs several areas of shared memory, and I am getting an > error ("No such device") on the second call to mmap(). The first call works > fine. > > Here a simple program that shows the error (compiled with > gcc -o mmaptest mmaptest.c -lrt):