Mail Archives: cygwin/2014/01/30/04:58:48
--lYetfuAxy9ic4HK3
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Jan 29 20:33, Marco Atzeri wrote:
>=20
>=20
> 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 w=
orks
> >>fine.
> >>
>=20
> >>
> >>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.
>=20
> just as info also on my
> Windows 7 Professional Ver 6.1 Build 7601 Service Pack 1
>=20
> CYGWIN_NT-6.1-WOW64 1.7.28s(0.271/5/3) 20140128 10:55:59 i686 Cygwin
> the program fails (No such device)
>=20
> 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
>=20
> >
> >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
>=20
>=20
> Marco
> Exception: STATUS_ACCESS_VIOLATION at rip=3D00180043471
> rax=3D000000097FE5A410 rbx=3D00000001802A60C0 rcx=3D00000001801CD300
> rdx=3D00000000FFF70000 rsi=3D000006FFFFF70000 rdi=3D0000000000000001
> r8 =3D000000000022A8A8 r9 =3D0000000000000000 r10=3D0000000000000000
> r11=3D0000000000000206 r12=3D0000000000090000 r13=3DFFFFFFFFFFF70000
> r14=3D00000001802A60E0 r15=3D000006FFFFF70000
> rbp=3D0000000000000000 rsp=3D000000000022A880
> program=3DE:\cygwin64\tmp\mmaptest64.exe, pid 1124, thread main
> cs=3D0033 ds=3D002B es=3D002B fs=3D0053 gs=3D002B ss=3D002B
> Stack trace:
> Frame Function Args
> 00000000000 00180043471 (00000040202, 0000022AA20, 00000000030, 00000004=
022)
> 00000000000 001800C6338 (00180161BCA, 00000000000, 0018006A22E, 000FFFFF=
FFF)
> 0000022AAF0 001801114BB (00000000000, 0018006A22E, 000FFFFFFFF, 00000000=
000)
> 0000022AAF0 04949435341 (0018006A22E, 000FFFFFFFF, 00000000000, 001802E1=
9D8)
> 0000022AAF0 00180161BCA (001800473E0, 00000000000, 00000000000, 001802E1=
0C8)
> 0000022AB80 001800481FA (00000000000, 00000000000, 00000000000, 00000000=
000)
> 00000000000 0018004611B (00000000000, 00000000000, 00000000000, 00000000=
000)
> 00000000000 0018004627E (00000000000, 00000000000, 00000000000, 00000000=
000)
> 00000000000 001004012B1 (00000000000, 00000000000, 00000000000, 00000000=
000)
> 00000000000 00100401010 (00000000000, 00000000000, 00000000000, 00000000=
000)
> 00000000000 00076B2652D (00000000000, 00000000000, 00000000000, 00076BA9=
300)
> 00000000000 00076EAC541 (00000000000, 00000000000, 00000000000, 00076BA9=
300)
> 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
--=20
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
--lYetfuAxy9ic4HK3
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAEBAgAGBQJS6iI+AAoJEPU2Bp2uRE+gJXAP/iIX6o2sgnpSOGuiQ4AIQlfV
DwDD/tKZe5nv9L1kpcaVFWH+MPyoakSjm4jDK3/tqjKyLdxqsLziOLSSKQt3Mb4v
08cPwjMh8n11z0rqv0YrXFaBCwtDG+147AYBDTz/VdiH/EI/naYJOrRF5FMJ1UfE
IatoFFPzZVlHDn42j6KoazJO1hy8WzR2m+FTyk+NiEJkCHf7GeHMkUWHGOpl8qMc
/ek2tn4Eam98r7q8n9+DuhAxWCgMwyn1R9SQHPMAjBcZ2d4YrBkIEgvP3JNW+0F1
ncauvCMziZWqA/yFK62yrEyCmDty69OuvJTpkYUYwMnx1ptyIjNDsH9UQxH2RqIv
SWI31QwRkdrvgnqQdLRKi+NVgTA14J6gkpGG2IN2yYHo5pzGzBz/5WrbalGv+cgs
SvCs6ufMd9o21/IVlL79a0dUQfkGduQpBMKfk3VU9dbDLAPn3MipHJVXhm5j+xJ4
/FYVqSp5XOeyH+wgqM0CbJ1WQCJFWXAd8ZFFhY4sAIA4SXT0hQuBglO9P1/sDqUi
Uc5wREavTbli7koZhbwX0J6gDuUbrRid/HPiafP1PnmdBoFFx46b8KkPcXaDIC+n
2nNkx7okdn5v9J4YUtAZ9otLRjDyoUZeah1Iqpi+4ywEg+A8rEfTqQCQWv+kBbtZ
wfx7hIm4/v9Qw2MKF0eS
=mHEc
-----END PGP SIGNATURE-----
--lYetfuAxy9ic4HK3--
- Raw text -