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
