That's what I though as well. However, just encountered segfaults on x64 read syscall. Although this one might be legit. On Wed, Oct 2, 2013 at 11:15 AM, Dave Jones <davej@xxxxxxxxxx> wrote: > On Wed, Oct 02, 2013 at 11:12:21AM -0700, Ildar Muslukhov wrote: > > I finally was able to reproduce that bug. In order to validate the > > assumption that the "syscall32 fix" patch introduced that bug I pulled > > the latest trinity source and removed the patch at question from the > > source (gladly patch was small). And I am still getting segfault. > > Thus, assumption that this patch introduced that bug looks less > > probable now. Furthermore, if you run trinity with a single 32 bit > > function (-c perf_event_open,32 for example) it runs just fine. > > > > Several observations from my runs: > > 1) Not all 32 bit calls end up in segfault. > > 2) All segfaults are calls to 32 bit syscall. > > > > Still digging into what causes this, will keep you posted. > > This may have been why I had this.. > > // FIXME: I forgot why this got disabled. Revisit. > // if (rand() % 100 < 10) > // shm->do32bit[childno] = TRUE; > > in choose_syscall_table. > > Probably an old bug that I've never found time to dig into. > > Dave > -- To unsubscribe from this list: send the line "unsubscribe trinity" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
