The return of ASAN issues

[Ben Cooksley]

On Mon, Jun 13, 2016 at 6:25 AM, Albert Astals Cid <aacid at kde.org> wrote:
> El dimarts, 31 de maig de 2016, a les 18:49:29 CEST, Ben Cooksley va escriure:
>> On Tue, May 31, 2016 at 9:36 AM, Albert Astals Cid <aacid at kde.org> wrote:
>> > El dilluns, 30 de maig de 2016, a les 19:42:38 CEST, Ben Cooksley va
> escriure:
>> >> Hi all,
>> >>
>> >> As you may recall, some time ago the CI scripts were adapted to
>> >> forcibly inject ASAN into all test processes launched on the CI system
>> >> to fix Marble's tests, as Marble does not use ECM and thus does not
>> >> enable ASAN as a result.
>> >>
>> >> Unfortunately this has bad effects with certain processes,
>> >> particularly Java based ones. This causes the tests of other projects
>> >> to fail as a result with segmentation faults, as they're incompatible
>> >> with forced ASAN injection - they have to actually be built with ASAN
>> >> for it to work.
>> >>
>> >> Can someone please investigate another solution?
>> >
>> > I know it's a workaround, but given Marble is a bit of an unique snowflake
>> > in that it doesn't want to use ECM because it adds 0.3MB of dependencies,
>> > can't we just apply the LD_PRELOAD workaround on the "marble" job level
>> > (afaik we can do those things)?
>>
>> With a maintenance cost. But yes, it could be done.
>
> A very low maitenance cost IMHO compared to your suggestion, half proof is
> that you got someone that volunteered to implement my suggestion (me and i
> think Friedrich volunteered for something similar) while noone volunteered to
> play with the cmake files.
>
> As I see it what you're asking for is more correct but has a much bigger
> coding cost and the solution to applying the workaround only to marble is
> probably a 5 minute change that alls us to move forward.

Let's hope this isn't a slippery slope. Special cases have a nasty
habit of accumulating.
I've implemented this now. In the event other projects need this sort
of treatment for $whateverReason we'll need to revisit doing this
properly in some form or another.

>
> Cheers,
>   Albert

Regards,
Ben

>
>>
>> > What you suggest would be superb correct-ness wise but it doesn't seem the
>> > more effort/result solution.
>>
>> It would also fix anyone who has compiled Frameworks with ASAN and
>> needs to use a build system from elsewhere which does not use ECM
>> (Such as QMake for instance, although why you'd use ASAN in Frameworks
>> and not your app is another thing altogether of course)
>>
>> > Cheers,
>> >
>> >   Albert
>>
>> Regards,
>> Ben
>>
>> >> As ASAN is contagious, I would suggest that any Framework which is
>> >> compiled using ASAN have adjustments made to it's *Config.cmake files
>> >> to ensure linking for any binary/library built with it is setup
>> >> properly. I've no idea how complicated that is to setup though.
>> >>
>> >> This would fix Marble's tests while allowing Skrooge's tests that
>> >> depend on Java to be unaffected (and I considered the original fix to
>> >> inject ASAN a bit hackish, so i'm not surprised it's had casualties)
>> >>
>> >> Cheers,
>> >> Ben
>> >> _______________________________________________
>> >> Kde-frameworks-devel mailing list
>> >> Kde-frameworks-devel at kde.org
>> >> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
>>
>> _______________________________________________
>> Kde-frameworks-devel mailing list
>> Kde-frameworks-devel at kde.org
>> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
>
>