On Wed Sep 17 08:31:26 2008, particle wrote: > On Tue, Sep 16, 2008 at 11:45 PM, Christoph Otto via RT > <[EMAIL PROTECTED]> wrote: > > On Tue Sep 16 15:00:24 2008, [EMAIL PROTECTED] wrote: > >> On Tuesday 16 September 2008 14:47:58 NotFound wrote: > >> > >> > > It certainly shouldn't segfault. But, the question is: why does it > >> > > segfault at 206 parameters? Throwing an exception to avoid an > >> error we > >> > > don't understand isn't good for the long-term health of the VM. > >> > > >> > The problem is located inside compilers/imcc/pcc.c:pcc_get_args > >> function. > >> > > >> > It has the comment /* XXX check avail len */ just at the point where > >> > the segfault happens. char buf[1024] is the variable overrunned. > >> > >> That sounds like a bog-standard static variable overflow, where each > >> parameter > >> requires five bytes of storage. If that's a good rule of thumb, we > >> could > >> malloc/free that buffer instead, and then beat anyone who uses more > >> than a > >> dozen parameters. > >> > >> -- c > >> > > > > > > Looking at the code, it's 5n+1. r31200 changes the static buffer to a > > dynamic one of the correct size. The original PIR code now runs without > > segfaulting, as does a version with 20,000 int params. make test also > > passes, so nothing new appears to be broken. > > > > With the assumption that the said beatings will be a manual process, I'm > > marking this resolved. > > > > you didn't mention it, but i sincerely hope you committed a test with > 20,000 params that proves this and makes sure we don't regress in a > future revision. parrot needs much more stress testing like this, and > it would be a shame to miss this opportunity. > ~jerry >
I didn't think of it until after I went to bed, but I added one with 1000 params in r31208 the next morning. The 20,000 param version took more than a second to run and I didn't see any reason to slow the tests down more than necessary.
