Okay, weird.

brewbuck · 04-01-2009, 07:21 PM

I'm doing this:

Code:

if(read(mMemFd, buf, PageSize()) != 4096)
    throw ProcException();

It's throwing. Why? Because read() is returning 4097?!

mMemFd is an open file descriptor on /proc/XXX/mem. Obviously, read() doesn't normally do this or the whole system would be breaking.

Kernel is Linux 2.6.20

Perspective · 04-01-2009, 07:30 PM

Did you check what PageSize() returns?

brewbuck · 04-01-2009, 07:34 PM

Quote:

Originally Posted by Perspective

Did you check what PageSize() returns?

PageSize() returns 4096. I committed the sin of not posting the original code. It's actually:

Code:

if(read(mMemFd, buf, PageSize()) != PageSize())

Perspective · 04-01-2009, 07:37 PM

maybe check if errno is being set after the call? That's pretty odd though.

brewbuck · 04-01-2009, 07:38 PM

Quote:

Originally Posted by Perspective

maybe check if errno is being set after the call? That's pretty odd though.

errno is 0, as expected. My only theory at this point is kernel bug, so I'm compiling a newer kernel right now...

brewbuck · 04-01-2009, 08:51 PM

Okay. So here's what was happening. I was calling read(), and if it failed, throwing an exception. Apparently, something during exception throw was resetting errno to 0. Silly mistake. Checking errno immediately after the call to read() shows EINVAL.

The man page said that this could be due to unaligned access. But the access is aligned. So something else must be causing it.

Turns out, I was able to read() from regions of memory less than 2 GB, but not > 2 GB (in this case, the stack of another process). That's because I was calling lseek(), which takes an off_t, which is a signed type. So my address was sign-extending and becoming negative.

Oddly lseek() does not report it as an error if you seek before the beginning of the file. I don't know if that's always true.

Solution? Switch over to lseek64() which has enough room in its off64_t for values larger than 2 GB.

I still think there is a bug somewhere, either the kernel or the C library. If errno was being set (and I proved it by making sure it was 0 beforehand), then read() should be returning -1. But it's not, it's returning some value which seems to be "random" yet somehow related to the parameters passed.

If I had been checking for error with:

Code:

if(read(...) < 0)

Then I would have completely missed this problem and probably would have wasted several more hours figuring it out.

04-01-2009, 07:21 PM	#1
brewbuck Senior software engineer Join Date: Mar 2007 Location: Portland, OR Posts: 5,768	Okay, weird. I'm doing this: Code: if(read(mMemFd, buf, PageSize()) != 4096) throw ProcException(); It's throwing. Why? Because read() is returning 4097?! mMemFd is an open file descriptor on /proc/XXX/mem. Obviously, read() doesn't normally do this or the whole system would be breaking. Kernel is Linux 2.6.20 __________________ "Congratulations on your purchase. To begin using your quantum computer, set the power switch to both off and on simultaneously." -- raftpeople@slashdot
brewbuck is offline

04-01-2009, 07:30 PM	#2
Perspective Crazy Fool Join Date: Jan 2003 Location: Canada Posts: 2,596	Did you check what PageSize() returns? __________________ jeff.bagu.org - Terrain rendering and other random stuff
Perspective is offline

04-01-2009, 07:37 PM	#4
Perspective Crazy Fool Join Date: Jan 2003 Location: Canada Posts: 2,596	maybe check if errno is being set after the call? That's pretty odd though. __________________ jeff.bagu.org - Terrain rendering and other random stuff
Perspective is offline

04-01-2009, 08:51 PM	#6
brewbuck Senior software engineer Join Date: Mar 2007 Location: Portland, OR Posts: 5,768	Okay. So here's what was happening. I was calling read(), and if it failed, throwing an exception. Apparently, something during exception throw was resetting errno to 0. Silly mistake. Checking errno immediately after the call to read() shows EINVAL. The man page said that this could be due to unaligned access. But the access is aligned. So something else must be causing it. Turns out, I was able to read() from regions of memory less than 2 GB, but not > 2 GB (in this case, the stack of another process). That's because I was calling lseek(), which takes an off_t, which is a signed type. So my address was sign-extending and becoming negative. Oddly lseek() does not report it as an error if you seek before the beginning of the file. I don't know if that's always true. Solution? Switch over to lseek64() which has enough room in its off64_t for values larger than 2 GB. I still think there is a bug somewhere, either the kernel or the C library. If errno was being set (and I proved it by making sure it was 0 beforehand), then read() should be returning -1. But it's not, it's returning some value which seems to be "random" yet somehow related to the parameters passed. If I had been checking for error with: Code: if(read(...) < 0) Then I would have completely missed this problem and probably would have wasted several more hours figuring it out. __________________ "Congratulations on your purchase. To begin using your quantum computer, set the power switch to both off and on simultaneously." -- raftpeople@slashdot
brewbuck is offline

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
weird things with my linked list of queue	-EquinoX-	C Programming	3	11-22-2008 11:23 PM
weird	kiz	C Programming	8	09-24-2007 01:16 AM
Weird Characters With GetDlgItemText	execute	Windows Programming	4	05-04-2006 04:53 PM
weird error	gandalf_bar	Linux Programming	2	07-17-2005 07:32 AM
Getting weird characters in Strings	steve8820	C Programming	3	09-18-2001 02:49 AM