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
