2010-05-14 06:43:41     Monster alloca() in uclibc getdents64 - sane?

Document created by Aaronwu Employee on Sep 26, 2013
Version 1Show Document
  • View in full screen mode

2010-05-14 06:43:41     Monster alloca() in uclibc getdents64 - sane?

Ian Jeffray (UNITED KINGDOM)

Message: 89404   

 

I've been trying to resolve a problem with calling readdir() on a FAT filesystem that only appears when calling from a pthread.   Investigations have lead me to write my own routines which syscall getdents64 and that's working flawlessly, so I turn my attention to libc.

 

In uClibc / libc / sysdeps / linux / common / getdents64.c  ... I find that it's doing an alloca() of 32KB.  Now that seems pretty scary for anything in FLATted MMUless land, nevermind when being called from a pthread.

 

Am I misunderstanding this code?  Is it really safe to call alloca() for such a huge amount?  I'm certainly getting stack corruption when using uclibc's functions and not when using my own calls to getdents64() so something around here is fishy.

 

Also, the code in uClibc / libc / sysdeps / linux / common / getdents.c looks pretty fishy to me... At the least, the memmove() on line 132 looks like it's overwriting the work from the previous lines and dp should be moving along by a different amount, and 'ret' should be getting updated.   I'm really confused.

QuoteReplyEditDelete

 

 

2010-05-14 08:37:54     Monster alloca() in uclibc getdents64 - sane?

Michael Hennerich (GERMANY)

Message: 89408    Our uclibc expert is currently on vacation. I'm sure he will get back on this.

In the meantime - to work around the alloca() issue in your threaded application - can you try to increase the stack size?

 

http://docs.blackfin.uclinux.org/doku.php?id=uclinux-dist:debugging_applications

 

pthread_attr_setstacksize (attr, stacksize)

 

-Michael

QuoteReplyEditDelete

 

 

2010-05-14 09:15:13     Re: Monster alloca() in uclibc getdents64 - sane?

Ian Jeffray (UNITED KINGDOM)

Message: 89409   

 

Hi Michael,

 

Yes, increasing the stack size does 'solve' the problem... has to be increased to about 80KB to cope with being presented with FAT systems with 64KB clusters.  Bad karma, but at least I believe I know what's been causing my crashes for the last few months now!   What I've actually done is just write my own lightweight variants of the dirent functions anyway... the copying of all the entries in uclibc seemed pretty naff and unnecessary.

 

Cheers,  I.

QuoteReplyEditDelete

Attachments

    Outcomes