I am using D & epoll on Fedora 3.12.10-300.fc20.x86_64 and am running into a very odd issue.

The data.ptr value of the epoll_event struct when it comes back from the epoll_wait call seems to have lost the top 32 bits.

GDB session produced the following:

Before epoll

$3 = {events = 1, data = {ptr = 0x7ffff7ee2e80, fd = -135385472, u32 = 4159581824, u64 = 140737352969856}}

(gdb) x/20g ev
0x7ffff7ee5ff0: 0x0000000000000001      0x00007ffff7ee2e80
0x7ffff7ee6000: 0x0000000000000000      0x0000000000000000

After epoll
$4 = {events = 1, data = {ptr = 0xf7ee2e80, fd = -135385472, u32 = 4159581824, u64 = 4159581824}}

0x7fffffffe0e0: 0x0000000000000001      0x00000000f7ee2e80
0x7fffffffe0f0: 0x0000000000000001      0x0000000000000000

A similar gdb session with a simple C program produced the following:
Before epoll
$1 = {events = 1, data = {ptr = 0x7fbe184d9d00, fd = 407739648, u32 = 407739648, u64 = 140454428253440}}

after epoll
$2 = {ptr = 0x7fbe184d9d00, fd = 407739648, u32 = 407739648, u64 = 1404544282534

Source is at https://bitbucket.org/sumitraja/sioford/src/64ee53513876c1763a5e04b9611da64a5d96cced/source/devent/eventqueue.d?at=master with break points at eventqueue.d:238 and eventqueue.d:253

I can't figure out what exactly I am doing wrong here so any insights would be of great help. I have seen the issue on Debian with a 3.2 kernel as well. Happens with both "DMD64 D Compiler v2.064" and the Fedora repository version of "LDC - the LLVM D compiler (0.12.0)" (Release     : 53.20130805git967b986.fc20).

Thanks

Sumit

On Wednesday, 19 February 2014 at 02:39:39 UTC, sumo wrote:
> I am using D & epoll on Fedora 3.12.10-300.fc20.x86_64 and am running into a very odd issue.

For giggles the D kevent version on FreeBSD has no problems (80079af00 is pointer to the event object):

Before kevent:
0x800799f40:    0x0000000000000007      0x000000000005ffff
0x800799f50:    0x0000000000000000      0x000000080079af00 <---
0x800799f60:    0x00000000004fdca0      0x0000000000000000
0x800799f70:    0x000000080079af80      0x0000000000000000
0x800799f80:    0x00000000004fcc60      0x0000000000000000
0x800799f90:    0x0000000000000000      0x0000000000000000
0x800799fa0:    0x0000000000508ae0      0x0000000000000000
0x800799fb0:    0x00000000d2040200      0x0000000000000000
0x800799fc0:    0x00000000005141a0      0x0000000000000000
0x800799fd0:    0x0000000800798fc0      0x0000000801817070


After kevent:
0x7fffffffd778: 0x0000000000000007      0x000000000000ffff
0x7fffffffd788: 0x0000000000000001      0x000000080079af00 <---
0x7fffffffd798: 0x0000000800798f40      0x00007fffffffd7c0
0x7fffffffd7a8: 0x000000000041deb0      0x000000080079af80
0x7fffffffd7b8: 0x0000000800798f40      0x00007fffffffd850
0x7fffffffd7c8: 0x00000000004222a3      0x0000000000405990
0x7fffffffd7d8: 0x00007fffffffd82f      0x0000000800798f40
0x7fffffffd7e8: 0x0000000000000000      0x0000000000422440
0x7fffffffd7f8: 0x000000080079af80      0x0000000000000000
0x7fffffffd808: 0x0000000000422380      0x0000000001807000

I couldn't get gdb to print the actual structure - <incomplete type>

On Wednesday, 19 February 2014 at 02:39:39 UTC, sumo wrote:
> I am using D & epoll on Fedora 3.12.10-300.fc20.x86_64 and am running into a very odd issue.
>

For anyone who runs in to this, it is a because the epoll_event struct is packed  on x86_64 bits processors. Have created a pull for druntime.

On Monday, 24 March 2014 at 20:45:13 UTC, sumo wrote:
> On Wednesday, 19 February 2014 at 02:39:39 UTC, sumo wrote:
>> I am using D & epoll on Fedora 3.12.10-300.fc20.x86_64 and am running into a very odd issue.
>>
>
> For anyone who runs in to this, it is a because the epoll_event struct is packed  on x86_64 bits processors. Have created a pull for druntime.

Thumb up !

On 3/24/14, sumo <sumitraja@gmail.com> wrote:
> For anyone who runs in to this, it is a because the epoll_event struct is packed  on x86_64 bits processors. Have created a pull for druntime.

I'm really surprised this wasn't caught sooner. I thought epoll was supposed to be popular. Maybe not so much in the context of D?

On Monday, 24 March 2014 at 23:16:38 UTC, Andrej Mitrovic wrote:
> On 3/24/14, sumo <sumitraja@gmail.com> wrote:
>> For anyone who runs in to this, it is a because the epoll_event
>> struct is packed  on x86_64 bits processors. Have created a pull
>> for druntime.
>
> I'm really surprised this wasn't caught sooner. I thought epoll was
> supposed to be popular. Maybe not so much in the context of D?

Here we are using epoll a lot, but right now we have custom declarations for external API.

---
Paolo