On Tue, 2021-02-09 at 09:36 +0800, lixiaokeng wrote: > > > > > I still don't fully understand. Above you said "this coredump > > doesn't > > seem to appear any more". Am I understanding correctly that you > > observed *other* core dumps instead? > > > > No, it is not "instead". > As shown in https://www.spinics.net/lists/dm-devel/msg45293.html, > there are some different crashes in multipathd with no code change. > When blocking of thread cancellation during > udev_monitor_receive_device(), > no crash in udev_monitor_receive_device happens but others still > exist. Now I got it, eventually :-) Thanks for the clarification. Would it be ossible for you to categorize the different issues and provide core dumps? You mentioned in the systemd issue that you were playing around with the gcc -fexceptions flag. As I remarked there - how did it get set in the first place? What distro are you using? > > > > The "best" solution would probably be to generally disallow > > cancellation, and only run pthread_testcancel() at certain points > > in > > the code where we might block (and know that being cancelled would > > be > > safe). That would not only make multipathd safer from crashing, it > > would also enable us to remove hundreds of ugly > > pthread_cleanup_push()/pop() calls from our code. > > > > Finding all these points would be a challenge though, and if we > > don't > > find them, we risk hanging on exit again, which is bad too, and was > > just recently improved. > > Do you mean some patches have been made to solve these problem? No. I could hack up some, but it will take some time. Regards, Martin -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
