[Development] What's the status of a moved-from object?

Elvis Stansvik elvstone at gmail.com
Tue May 21 10:26:45 CEST 2019

Den tis 21 maj 2019 kl 09:55 skrev Konstantin Shegunov <kshegunov at gmail.com>:
> On Tue, May 21, 2019 at 9:49 AM Mutz, Marc via Development <development at 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

"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 at newton ~]$ apt-cache policy libqt5widgets5-dbgsym
  Installerad: 5.9.5+dfsg-0ubuntu2
  Kandidat:    5.9.5+dfsg-0ubuntu2
 *** 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 at newton ~]$


>> 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&section=all&arch=any&searchon=names&keywords=libqt5core
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> https://lists.qt-project.org/listinfo/development

More information about the Development mailing list