Hi,
Have you ever seen crashes in the CI system that ended up in
getenv? For example in
http://testresults.qt.io/ci/QtBase_5.4.2_Integration/build_00020/linux-g++_no-widgets_Ubuntu_12.04_x64/log.txt.gz
There are many more of these kinds of crashes throughout our
tests and whenever it h
On 2015-04-28 04:52, Simon Hausmann wrote:
> [getenv/setenv not thread safe]
>
> There are various options about what we can do with different degrees of
> "perfection",
> but ultimately it's all going to require a compromise. The option that we are
> favoring
> at the moment is two-fold:
>
> 1
On Tuesday, April 28, 2015 10:26:13 AM Matthew Woehlke wrote:
> On 2015-04-28 04:52, Simon Hausmann wrote:
> > [getenv/setenv not thread safe]
> >
> > There are various options about what we can do with different degrees of
> > "perfection", but ultimately it's all going to require a compromise. T
On Tuesday 28 April 2015 10:52:32 Simon Hausmann wrote:
> There are various options about what we can do with different degrees of
> "perfection", but ultimately it's all going to require a compromise. The
> option that we are favoring at the moment is two-fold:
>
> 1) Policy in Qt is to use the Q
On Wednesday 29 April 2015 11:55:48 Marc Mutz wrote:
> 1. man putenv on Linux says that since glibc 2.1, putenv is reentrant
http://osxr.org/glibc/source/stdlib/setenv.c#0109
but getenv isn't protected by any lock, indeed:
http://osxr.org/glibc/source/stdlib/getenv.c#0033
--
Marc Mutz | Senio
On Wednesday, April 29, 2015 11:55:48 AM Marc Mutz wrote:
> On Tuesday 28 April 2015 10:52:32 Simon Hausmann wrote:
> > There are various options about what we can do with different degrees of
> > "perfection", but ultimately it's all going to require a compromise. The
> > option that we are favori
On Wednesday 29 April 2015 10:02:29 Simon Hausmann wrote:
> In my opinion the overhead of the read-write lock is not worth the
> prospective gain in the unlikely event of repeated concurrent environment
> access.
Agreed.
An RWLock has a benefit when there are multiple *read* threads trying to acc
On Wednesday 29 April 2015 11:15:21 Simon Hausmann wrote:
> How can we do this in Qt and in our tests?
The problem here is the fact that they're tests. Unlike regular applications,
we're doing things at times when applications shouldn't be doing the same
action.
Strictly speaking, we should fix
On Wednesday 29 April 2015 11:15:21 Simon Hausmann wrote:
> > 1. man putenv on Linux says that since glibc 2.1, putenv is reentrant. In
> >
> >any case, it's almost trivial to fix this in libc (using CAS, as Ossi
> >suggested in a comment on v1 of the patch), but impossible outside.
>
> Do
On Thursday, April 30, 2015 10:50:59 AM Marc Mutz wrote:
> > > 2. what business does a program have, anyway, of modifying the
> > >
> > >environment after threads may have started? Such code should be
> > >fixed.
> > >Making the Qt wrappers "save" could lead to more code doing nonsense
Marc Mutz wrote:
> Tests are presumably easy. If everything else fails, QtTest could execute
> itself anew for each test. After a quick scan, the only thing I'm worried
> about in QtBase is qglxconvenience.cpp, which temporarily modifies the
> environment.
That would be my code. The environment is
Simon Hausmann wrote:
> Yes, this isn't perfect, because we still include large quantities of code
> in src/3rdparty in Qt that has unprotected calls to getenv(). But then
> that hasn't stopped us from patching that code in the past.
That will not help on distributions using system copies of third
12 matches
Mail list logo
