Mac - 4.7.1 crash from normal user (not admin)

[Linus Torvalds]

On Tue, Oct 24, 2017 at 11:56 AM, Philippe Massart
<philippe at philmassart.net> wrote:
>
> I tested the last release from another account on my computer (using OS X High Sierra).
>
>  No problem while importing data from my dive computer under the admin session.
>
> But it crashes when trying to download dives from another computer under my son’s account (normal user).

Which kind of dive computer? Are they the same?

> The error log as attachment.

Sadly, the call trace is annoyingly incomplete exactly for the interesting case:

Thread 15 Crashed:: DownloadThread
0   libsystem_c.dylib                   0x00007fff67a5d452 strlen + 18
1   libsystem_c.dylib                   0x00007fff67aa1c55 __vfprintf + 4711
2   libsystem_c.dylib                   0x00007fff67ac90a9 __v2printf + 473
3   libsystem_c.dylib                   0x00007fff67aae4c7 _vsnprintf + 415
4   libsystem_c.dylib                   0x00007fff67aae57a vsnprintf + 80
5   org.subsurface-divelog              0x000000010ea7f406 0x10e835000 + 2401286
6   org.subsurface-divelog              0x000000010ea8030f 0x10e835000 + 2405135
7   org.subsurface-divelog              0x000000010eb6badf
device_event_emit + 687
8   org.subsurface-divelog              0x000000010eb9c30b 0x10e835000 + 3568395
9   org.subsurface-divelog              0x000000010eb6bb72
dc_device_foreach + 98
10  org.subsurface-divelog              0x000000010ea7f23f 0x10e835000 + 2400831
11  org.subsurface-divelog              0x000000010ea7f005
do_libdivecomputer_import + 613
12  org.subsurface-divelog              0x000000010eb21b07
DownloadThread::run() + 775

so it's device_event_emit() that calls _something_ that in turn does
vsnprintf() with a bad pointer or similar, but the address decoding
doesn't work for that callback in subsurface for some odd reason.

Don't ask me why, I don't know OS X.

But I _suspect_ that it's some event that your son has that we handle
incorrectly, and that you don't (possibly because you had totally
different dive computers, but possibly even if the dive computers are
the same, and your son just had an event you didn't have).

The most obvious cases would be that device_event_emit() calls
"evet_cb()", which calls "dev_info()", which then calls "vsnprintf()".
That would match the call chain above.

The main suspicious case would be

        case DC_EVENT_DEVINFO:
                ...
                dev_info(devdata, translate("gettextFromC", "model=%s
firmware=%u serial=%u"),
                         devdata->product, devinfo->firmware, devinfo->serial);

which could have the problem you see if the product/firmware/serial
information isn't correctly filled in. The other cases don't seem to
be printing strings.

Knowing which dive computer it is, I can try to see what
libdivecomputer does for that dive computer...

               Linus