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.
> >>
> 
> >>
> >>The problem does not seem to depend on the size of the requested memory. The
> >>program
> >>always returns with "Couldn't map memory for /block2 (No such device)"
> >
> >Try stracing it.  I tried it on the latest Cygwin from CVS as well
> >as on Cygwin 1.7.27 (32 bit versions) and it works fine for me.
> 
> just as info also on my
> Windows 7 Professional Ver 6.1 Build 7601 Service Pack 1
> 
> CYGWIN_NT-6.1-WOW64  1.7.28s(0.271/5/3) 20140128 10:55:59 i686 Cygwin
> the program fails (No such device)
> 
> and it segfaults on 64 bit
> CYGWIN_NT-6.1 1.7.28s(0.271/5/3) 20140128 10:55:59 x86_64 Cygwin
> attached the stackdump
> 
> >
> >Your testcase is missing an ftruncate or two., btw.  I guess you're
> >aware of that and just dropped them to get a the simple testcase.
> >
> >
> >Corinna
> 
> 
> Marco

> Exception: STATUS_ACCESS_VIOLATION at rip=00180043471
> rax=000000097FE5A410 rbx=00000001802A60C0 rcx=00000001801CD300
> rdx=00000000FFF70000 rsi=000006FFFFF70000 rdi=0000000000000001
> r8 =000000000022A8A8 r9 =0000000000000000 r10=0000000000000000
> r11=0000000000000206 r12=0000000000090000 r13=FFFFFFFFFFF70000
> r14=00000001802A60E0 r15=000006FFFFF70000
> rbp=0000000000000000 rsp=000000000022A880
> program=E:\cygwin64\tmp\mmaptest64.exe, pid 1124, thread main
> cs=0033 ds=002B es=002B fs=0053 gs=002B ss=002B
> Stack trace:
> Frame        Function    Args
> 00000000000  00180043471 (00000040202, 0000022AA20, 00000000030, 00000004022)
> 00000000000  001800C6338 (00180161BCA, 00000000000, 0018006A22E, 000FFFFFFFF)
> 0000022AAF0  001801114BB (00000000000, 0018006A22E, 000FFFFFFFF, 00000000000)
> 0000022AAF0  04949435341 (0018006A22E, 000FFFFFFFF, 00000000000, 001802E19D8)
> 0000022AAF0  00180161BCA (001800473E0, 00000000000, 00000000000, 001802E10C8)
> 0000022AB80  001800481FA (00000000000, 00000000000, 00000000000, 00000000000)
> 00000000000  0018004611B (00000000000, 00000000000, 00000000000, 00000000000)
> 00000000000  0018004627E (00000000000, 00000000000, 00000000000, 00000000000)
> 00000000000  001004012B1 (00000000000, 00000000000, 00000000000, 00000000000)
> 00000000000  00100401010 (00000000000, 00000000000, 00000000000, 00000000000)
> 00000000000  00076B2652D (00000000000, 00000000000, 00000000000, 00076BA9300)
> 00000000000  00076EAC541 (00000000000, 00000000000, 00000000000, 00076BA9300)
> End of stack trace

Sorry guys, but it still works fine for me.  I tried your testcase on W7
32, W7 64 in 32 and 64 bit, and on Windows 8.1 64 in 32 and 64 bit.  I
tried it with Cygwin 1.7.27 and with the latest snapshot.  I'm always
getting the output "Shared memory initialized" and no error at all.

The strace output as well as the above stackdump are plain puzzeling.
When you use shm_open("/foo", the Cygwin emulation of the call boils
down to a simple call open ("/dev/shm/foo").  So, mmaping a POSIX shared
mem region is in fact the same as mmaping a file, and that works usally
pretty well.

In the strace output, the incoming descriptor is recognized as file, but
then, nevertheless, the wrong fhandler mmap method is called, the base
method which always returns ENODEV.  In case of the above stackdump,
mmap crashes in a perfectly harmless spot, which is called for each mmap
on any file.

Any chance one of you guys could debug this further, by stepping through
the Cygwin mmap64 function, preferredly using the latest snapshot or,
a self-built Cygwin DLL from?


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat