|
From: Julian S. <js...@ac...> - 2002-10-18 20:46:22
|
> I already put 03-poll-select and 04-lax-ioctls into 1.0.4 and will > merge the result to the head shortly. I considered 02-sysv-msg but > concluded it too risky for the stable branch > > Why? Clearly nobody is using SYSV messaging in threaded programs > because it is currently completely broken. That patch makes it much > better (and might even be problem-free). Ah, I remember now. This is the situation on my R H 7.2 box; YMMV. sewardj@phoenix:~/VgHEAD/valgrind$ nm /lib/libc-2.2.4.so | grep msgsnd 000e76c8 T msgsnd sewardj@phoenix:~/VgHEAD/valgrind$ nm /lib/libc-2.2.4.so | grep msgrcv 000e771c T msgrcv sewardj@phoenix:~/VgHEAD/valgrind$ nm /lib/libpthread-0.9.so | grep msgsnd sewardj@phoenix:~/VgHEAD/valgrind$ nm /lib/libpthread-0.9.so | grep msgrcv IOW, msgsnd/msgrcv are exported as strong text symbols from libc, and not at all from libpthread. Your patch adds them to valgrind's libpthread.so. So any threaded program running on V will have two definitions of them to choose from, and it is unclear which it will get. If the libc version was defined as a weak symbol, then V's implementation would definitely overrride it (and many libc things are indeed exported weakly) but that is not the case. Does that make sense? Is there some other behaviour of the dynamic linker which might save the day and avoid this issue? I don't know much about ld.so; perhaps you understand more about all this? > My current plans for it are: > - beef up reporting (starting by stealing chunks of memcheck) > - suppress duplicate errors > - investigate the state of the stack on thread startup > - make the memory granularity a compile-time setting for experiments > - implement the thread lifetime segment stuff (which may help with the > thread stack state problem; not sure yet) > > I hope to make some substantial progress in the next week or so. That's great. You have my encouragement :) J |