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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
