Re: problem in using SampleFilterScheme
Re: problem in using SampleFilterScheme
- Subject: Re: problem in using SampleFilterScheme
- From: Phil Jordan <email@hidden>
- Date: Wed, 04 Jul 2012 13:38:12 +0200
On Wed, Jul 4, 2012 at 4:57 AM, Li Flost.Dexiong <email@hidden> wrote:
> My change like this:
>
> 1) add a probe function to SampleFilterScheme; this function implement as description in my last mail.
Without seeing the code for probe() I can still only guess.
Specifically, it'd be interesting how you're allocating the read
buffer and calling read() inside probe().
> 2) modify read function declaration to
> virtual void read(IOService* client,
> UInt64 byteStart,
> IOMemoryDescriptor* buffer,
> IOStorageAttributes* attributes,
> IOStorageCompletion * completion);
>
> and its implementation is:
>
> void com_apple_dts_driver_SampleFilterScheme::read(IOService* __attribute__ ((unused)) client,
> UInt64 byteStart,
> IOMemoryDescriptor* buffer,
> IOStorageAttributes* attributes,
> IOStorageCompletion *completion)
> {
>
> char pname[4096] = {'\0'};
> proc_selfname(pname, sizeof(pname));
> DEBUG_LOG("%s[%p]::%s(%p, %llu, %p, %p, %p)\n", getName(), this, __FUNCTION__, client, byteStart, buffer, completion);
> printf("%s->%s[%p]::%s(%p, %llu, %p, %p)\n",pname, getName(), this, __FUNCTION__, client, byteStart, buffer, completion);
>
> getProvider()->read(this, byteStart, buffer, attributes, completion);
> }
You're allocating 4KB on the stack in this function. Don't. You're
only using it for printing anyway, so limit it to 64 characters or so.
Even better, do the debug output in a helper function so the stack
space is returned before you get to the provider's read() method.
Allocate larger buffers (more than a few dozen bytes) dynamically on
the "heap". The typical storage driver stack on OSX can already
produce some very deep stacks - between PCI, the AHCI driver, various
IOStorage family stuff, the partition scheme, the file system, and VFS
this can easily add up to 10-12K before you add your own layer. It's
therefore really important to keep your stack usage to a minimum,
especially in "forwarding" methods like read().
> I'm curious about
> 1) why the GetProvider() will turn back to my class?
It won't. It's probably something else. In particular, it looks to me
from the stack trace (first argument to your methods) like your 'this'
pointer is something different every time. Could it be that you're
ending up with mulitple instances of your filter scheme stacked on top
of each other? I strongly recommend capturing firewire/serial port
kprintf() and gdb via firewire/ethernet from a second mac. It saves an
enormous amount of time stumbling in the dark.
> 2) if the stack is small to 16KB, but in my probe function, i just using a array of 4096B. how can this be overflow?
Look at your bottom stack pointer: 0x30ca3fc8 - you can round this up
to the next page boundary, i.e. 0x30ca4000.
and the top stack frame: 0x30ca0d18
the difference between these is 0x32E8 or 13032.
As com_apple_dts_driver_SampleFilterScheme::read() tries to allocate
4K, this pushes it over 16K, thus blowing the stack.
Hope that helps,
phil
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden