Bug 673193

Summary: io_getevents does not work properly when called from within a shared library
Product: [Fedora] Fedora Reporter: Jeffrey M. Birnbaum <jmbnyc>
Component: libaioAssignee: Jeff Moyer <jmoyer>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 14CC: jmoyer
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-01-27 18:04:36 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
code + README file
none
makefile none

Description Jeffrey M. Birnbaum 2011-01-27 17:15:32 UTC
Created attachment 475645 [details]
code + README file

Description of problem:
When io_getevents is called from a shared library it returns immediately regardless of whether a timeout is specified. The same exact code when compiled into a regular program works as expected.

Version-Release number of selected component (if applicable):

libaio-0.3.109-2.fc13.x86_64
libaio-devel-0.3.109-2.fc13.x86_64

How reproducible:
100%

Steps to Reproduce:
1. see README file inside attachment for instructions to reproduce
2.
3.
  
Actual results:
program is intended to wait 10 seconds inside io_getevents before returning, but instead returns immediately.

Expected results:
program should wait 10 seconds inside io_getevents call

Additional info:
See attached tar ball with code and instructions to demonstrate the bug

Comment 1 Jeffrey M. Birnbaum 2011-01-27 17:36:31 UTC
Created attachment 475648 [details]
makefile

Makefile to make easier to show bug:

gmake works
./aiobug.works
gmake bug
./aiobug.bug

Comment 2 Jeff Moyer 2011-01-27 18:04:23 UTC
Your problem can be solved by linking the shared object with libaio.  Your code ended up in the compat code, which treated the wrong variable as the timespec, causing the problem.  If you still believe there is a problem, feel free to reopen the bug and assign it to the linker.  I'm sure they can at least give you a more satisfying answer than I can.

Note: In the future, if you're going to attach test code, be sure it's freely licensed so it can make its way into regression test suites.

Comment 3 Jeffrey M. Birnbaum 2011-01-27 18:14:19 UTC
Ah, interesting, I had a feeling that the stack was getting misread and now I understand why although I am not expert enough to exactly know why it ended up in 'compat code' (although I have seen that code in the library so I see how params could get misread). 

Thanks for the Note, I should have removed the copyright (my emacs file open hook mode sticks it into every file I create and I did not event bother with it).