Den tis 21 maj 2019 kl 09:55 skrev Konstantin Shegunov <kshegu...@gmail.com>: > > On Tue, May 21, 2019 at 9:49 AM Mutz, Marc via Development > <development@qt-project.org> wrote: >> >> Oh, a nullptr deref is pretty clear in a backtrace. > > > Indeed, but my point is that it's relatively useless for the user (or for the > developer for that matter). As you pointed out the dev sees the nullptr > dereferencing instantly, the user just gets a crash. The assert is just > superfluous is what I'm saying. > >> >> Even in a release >> build, if you installed the debug symbol package that does with the >> distribution's version of Qt. > > > Humor me, will you? [1]
They will not show up in the web search (I think). They are however available in the debian-debug archive, see https://wiki.debian.org/AutomaticDebugPackages "The automatic dbgsym packages are available from a separate archive. Please fetch these from http://deb.debian.org/debian-debug/ (backed by http://debug.mirrors.debian.org/debian-debug/). They are also available on http://snapshot.debian.org/. They are only available for stable, proposed-updates, backports, testing, unstable and experimental at this point in time, optionally also under the release's codename. " E.g. I if you run testing, think you would add: deb http://deb.debian.org/debian-debug/ testing-debug main to your sources.list. For Ubuntu, I think the archive is called http://ddebs.ubuntu.com. E.g. I have deb http://ddebs.ubuntu.com bionic main restricted universe multiverse deb http://ddebs.ubuntu.com bionic-updates main restricted universe multiverse here on Kubuntu 18.04, and I have e.g: [estan@newton ~]$ apt-cache policy libqt5widgets5-dbgsym libqt5widgets5-dbgsym: Installerad: 5.9.5+dfsg-0ubuntu2 Kandidat: 5.9.5+dfsg-0ubuntu2 Versionstabell: *** 5.9.5+dfsg-0ubuntu2 500 500 http://ddebs.ubuntu.com bionic-updates/main amd64 Packages 100 /var/lib/dpkg/status 5.9.5+dfsg-0ubuntu1 500 500 http://ddebs.ubuntu.com bionic/main amd64 Packages [estan@newton ~]$ Cheers, Elvis > >> >> Please, you debug against a release build, and complain that you don't >> get debug checks? > > > To take your previous example. > > QPen pen1 = ~~~; > QPen pen2 = std::move(pen1); > > // ... Some code > > pen1.color(); // Ooops > >> You're missing out on 4000 other checks that way, too! > > > Yes, I already aknowledged that. And it's fine if I'm debugging into Qt. If > not, I get segfault. And as it happens I have enough builds, so even if that > happens and I can't switch kits and step into Qt, not every one user does > have that at their fingertips, however. > Having documentation that spells such behaviour clearly, would be > satisfactory to me, that's why I was inquiring on *how* the problem, which is > a real one, can be mitigated. > >> >> That said, I'm pretty sure that a static analyzer can find uses of >> objects in partially-formed state with local analysis. > > > QPen pen; > QColor color = pen.color(); > > If the analyzer can see the above as dangerous, i.e. touching an object with > an invalid state (i.e. d-ptr is null) as dangerous, I'm satisfied. > > [1]: > https://packages.debian.org/search?suite=testing§ion=all&arch=any&searchon=names&keywords=libqt5core > _______________________________________________ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
