| Message ID | 5435437D.4020407@partner.samsung.com |
|---|---|
| State | New |
| Headers | show |
On 08/10/14 15:00, Maxim Ostapenko wrote: > Hm, as I see, others testsuites such as gfortran.exp, go.exp etc. do not > call restore_ld_library_path at all. Perhaps we could simply follow this > way? > > Would failing tests still fail if remove restore_ld_library_path from > {asan, tsan, ubsan}_finish? Hi Maxim, verified those fails gone away on check-gcc. but not sure whether this remove will cause problem on other test environments which they are aimed to solve. -- Jiong > > On 10/08/2014 03:40 PM, Marcus Shawcroft wrote: >> On 8 October 2014 11:10, Maxim Ostapenko >> <m.ostapenko@partner.samsung.com> wrote: >>> Does it work without restore_ld_library_path in {asan, ubsan, tsan}_finish? >>> >>> I see two opportunities to fix the issue: >>> >>> 1) Implement a stack of saved contexts. >>> >>> 2) Implement new functions, say {asan, ubsan, tsan}_restore_ld_library_path, >>> to be able {asan, ubsan, tsan}_finish functions restore context correctly. >>> >>> What solution is preferable? >> Option 1 has the advantage that it places all of the context save and >> restore in one place rather than spreading it around the >> infrastructure. >> >> Please can we revert this patch while a correct implementation is being worked? >> >> Cheers >> /Marcus >>
Hi Jiong, I couldn't reproduce tests failures on my box, perhaps I missed something. How can I test this? -Maxim On 10/08/2014 06:30 PM, Jiong Wang wrote: > > On 08/10/14 15:00, Maxim Ostapenko wrote: >> Hm, as I see, others testsuites such as gfortran.exp, go.exp etc. do not >> call restore_ld_library_path at all. Perhaps we could simply follow this >> way? >> >> Would failing tests still fail if remove restore_ld_library_path from >> {asan, tsan, ubsan}_finish? > Hi Maxim, > > verified those fails gone away on check-gcc. > > but not sure whether this remove will cause problem on other test > environments which they are aimed to solve. > > -- Jiong > >> >> On 10/08/2014 03:40 PM, Marcus Shawcroft wrote: >>> On 8 October 2014 11:10, Maxim Ostapenko >>> <m.ostapenko@partner.samsung.com> wrote: >>>> Does it work without restore_ld_library_path in {asan, ubsan, >>>> tsan}_finish? >>>> >>>> I see two opportunities to fix the issue: >>>> >>>> 1) Implement a stack of saved contexts. >>>> >>>> 2) Implement new functions, say {asan, ubsan, >>>> tsan}_restore_ld_library_path, >>>> to be able {asan, ubsan, tsan}_finish functions restore context >>>> correctly. >>>> >>>> What solution is preferable? >>> Option 1 has the advantage that it places all of the context save and >>> restore in one place rather than spreading it around the >>> infrastructure. >>> >>> Please can we revert this patch while a correct implementation is >>> being worked? >>> >>> Cheers >>> /Marcus >>> > > >
On 08/10/14 17:19, Maxim Ostapenko wrote: > Hi Jiong, > > I couldn't reproduce tests failures on my box, perhaps I missed > something. How can I test this? Hi Maxim, What I mean is after this patch, those fails gone away on my test environment also. I am just not sure whether the remove will cause it work on your and my test environment but fail on others. because looks like these restore_ld_library_path is added deliberately. Regards, Jiong > > -Maxim > On 10/08/2014 06:30 PM, Jiong Wang wrote: >> On 08/10/14 15:00, Maxim Ostapenko wrote: >>> Hm, as I see, others testsuites such as gfortran.exp, go.exp etc. do not >>> call restore_ld_library_path at all. Perhaps we could simply follow this >>> way? >>> >>> Would failing tests still fail if remove restore_ld_library_path from >>> {asan, tsan, ubsan}_finish? >> Hi Maxim, >> >> verified those fails gone away on check-gcc. >> >> but not sure whether this remove will cause problem on other test >> environments which they are aimed to solve. >> >> -- Jiong >> >>> On 10/08/2014 03:40 PM, Marcus Shawcroft wrote: >>>> On 8 October 2014 11:10, Maxim Ostapenko >>>> <m.ostapenko@partner.samsung.com> wrote: >>>>> Does it work without restore_ld_library_path in {asan, ubsan, >>>>> tsan}_finish? >>>>> >>>>> I see two opportunities to fix the issue: >>>>> >>>>> 1) Implement a stack of saved contexts. >>>>> >>>>> 2) Implement new functions, say {asan, ubsan, >>>>> tsan}_restore_ld_library_path, >>>>> to be able {asan, ubsan, tsan}_finish functions restore context >>>>> correctly. >>>>> >>>>> What solution is preferable? >>>> Option 1 has the advantage that it places all of the context save and >>>> restore in one place rather than spreading it around the >>>> infrastructure. >>>> >>>> Please can we revert this patch while a correct implementation is >>>> being worked? >>>> >>>> Cheers >>>> /Marcus >>>> >> >> >
diff --git a/gcc/testsuite/lib/asan-dg.exp b/gcc/testsuite/lib/asan-dg.exp index 9769138..c98fd3c 100644 --- a/gcc/testsuite/lib/asan-dg.exp +++ b/gcc/testsuite/lib/asan-dg.exp @@ -132,7 +132,6 @@ proc asan_finish { args } { unset TEST_ALWAYS_FLAGS } } - restore_ld_library_path_env_vars } # Symbolize lines like diff --git a/gcc/testsuite/lib/tsan-dg.exp b/gcc/testsuite/lib/tsan-dg.exp index 54ec404..6f7a4d9 100644 --- a/gcc/testsuite/lib/tsan-dg.exp +++ b/gcc/testsuite/lib/tsan-dg.exp @@ -143,5 +143,4 @@ proc tsan_finish { args } { } else { unset dg-do-what-default } - restore_ld_library_path_env_vars } diff --git a/gcc/testsuite/lib/ubsan-dg.exp b/gcc/testsuite/lib/ubsan-dg.exp index 5a7a653..87c460f 100644 --- a/gcc/testsuite/lib/ubsan-dg.exp +++ b/gcc/testsuite/lib/ubsan-dg.exp @@ -114,5 +114,4 @@ proc ubsan_finish { args } { unset TEST_ALWAYS_FLAGS } } - restore_ld_library_path_env_vars }
Hm, as I see, others testsuites such as gfortran.exp, go.exp etc. do not call restore_ld_library_path at all. Perhaps we could simply follow this way? Would failing tests still fail if remove restore_ld_library_path from {asan, tsan, ubsan}_finish? On 10/08/2014 03:40 PM, Marcus Shawcroft wrote: > On 8 October 2014 11:10, Maxim Ostapenko > <m.ostapenko@partner.samsung.com> wrote: >> Does it work without restore_ld_library_path in {asan, ubsan, tsan}_finish? >> >> I see two opportunities to fix the issue: >> >> 1) Implement a stack of saved contexts. >> >> 2) Implement new functions, say {asan, ubsan, tsan}_restore_ld_library_path, >> to be able {asan, ubsan, tsan}_finish functions restore context correctly. >> >> What solution is preferable? > Option 1 has the advantage that it places all of the context save and > restore in one place rather than spreading it around the > infrastructure. > > Please can we revert this patch while a correct implementation is being worked? > > Cheers > /Marcus >