This is an archive of the discontinued LLVM Phabricator instance.

[LIBOMPTARGET]Fix PR44933: fix crash because of the too early deinitialization of libomptarget.
ClosedPublic

Authored by ABataev on Feb 19 2020, 7:51 AM.

Details

Summary

Instead of using global variables with unpredicted time of
deinitialization, use dynamically allocated variables with functions
explicitly marked as global constructor/destructor and priority. This
allows to prevent the crash because of the incorrect order of dynamic
libraries deinitialization.

Diff Detail

Event Timeline

ABataev created this revision.Feb 19 2020, 7:51 AM
Herald added a project: Restricted Project. · View Herald TranscriptFeb 19 2020, 7:51 AM

I understand the rationale behind this patch, although I haven't been able to reproduce the problem. Maybe we are just being proactive here and stay on the safe side before any problem actually occurs. I'll keep the review open for a while just in case someone wants to raise any concerns, but to me it looks good.

I understand the rationale behind this patch, although I haven't been able to reproduce the problem. Maybe we are just being proactive here and stay on the safe side before any problem actually occurs. I'll keep the review open for a while just in case someone wants to raise any concerns, but to me it looks good.

Did you try to run the test without this patch? For me, it crashes, just like the reproducer from the report

Did you try to run the test without this patch? For me, it crashes, just like the reproducer from the report

Yes, I ran the provided test and for me it works correctly without the patch. But the nature of the problem makes reproducibility somewhat unpredictable, maybe on my system the RTL globals just happen to be deinitialized at the right time.

Maybe it is just the problem of the test. I have CHECK-NOT in it to detect a possible crash. Maybe, just missed a variant for your system. Did you try the reproducer from the error report?

Maybe it is just the problem of the test. I have CHECK-NOT in it to detect a possible crash. Maybe, just missed a variant for your system. Did you try the reproducer from the error report?

Yes, the reproducer works for me without this patch. But I'm targeting x86_64-pc-linux-gnu instead of nvptx64-nvidia-cuda, that might explain the difference in behavior (although I doubt it).

Maybe it is just the problem of the test. I have CHECK-NOT in it to detect a possible crash. Maybe, just missed a variant for your system. Did you try the reproducer from the error report?

Yes, the reproducer works for me without this patch. But I'm targeting x86_64-pc-linux-gnu instead of nvptx64-nvidia-cuda, that might explain the difference in behavior (although I doubt it).

No, I rather doubt in it. The test and the reproducer crash for me even when the host triple is specified as OpenMP target device.

grokos accepted this revision.Feb 24 2020, 3:05 PM

I think we should move forward (I still haven't been able to reproduce the problem). LGTM.

This revision is now accepted and ready to land.Feb 24 2020, 3:05 PM
This revision was automatically updated to reflect the committed changes.