qTox "Not responding" after update on OS X version 10.11.3

[fmvin]

Application cannot start after Mac was updated to OS 10.11.3

qTox was installed from qTox-OSX-1.2.4.307.dmg

[fmvin]

OS X log attached osx_log.txt

[zetok]

Version: v1.2-307-g26e7bde (1.2.2)

It's kinda weird that it says that it's a 1.2.2 version, even though 26e7bde was not included in 1.2.2 and AFAICS it's only available on master. I guess that it should say ~nightly, @RowenStipe ?

[tux3]

It's kinda weird that it says that it's a 1.2.2 version

That's because 1.2.2 was tagged on master then merged on stable, but all the other tags were made directly on stable so the last tag on master is 1.2.2. I guess I could pick some arbitrary commit on master and tag it "nightly".

[zetok]

That's because 1.2.2 was tagged on master then merged on stable, but all the other tags were made directly on stable so the last tag on master is 1.2.2. I guess I could pick some arbitrary commit on master and tag it "nightly".

Err.

Eh, from what I see then, tags/versions as they are, they're ~useless. And adding some arbitrary nightly tag would only make things even messier.

[RowenStipe]

I'm not sure where in the code it's getting that it's version 1.2.2 when I'm building it with the master branch. tux3 answers it.

But as for the issue, @fmvin could you use Terminal to launch qTox and see what is happening?
In terminal cd to the dir your running qTox from and do ./qTox.app/Contents/MacOS/qtox to start qTox.

I honestly can't tell you what's wrong from your log alone.

[fmvin]

Please take a look:

./qTox.app/Contents/MacOS/qtox
[15:00:04.204] ../qTox/src/platform/install_osx.cpp:116 : Debug: OS X: Old settings directory not detected
[15:00:04.204] ../qTox/src/persistence/settings.cpp:120 : Debug: "Loading settings from /Users/mss/Library/Application Support/Tox/qtox.ini"
[15:00:04.205] ../qTox/src/ipc.cpp:46 : Debug: Our global IPC ID is  13814388945268263087
[15:00:04.205] ../qTox/src/ipc.cpp:64 : Debug: Attaching to the global shared memory
[15:00:04.205] ../qTox/src/ipc.cpp:259 : Debug: Previous owner timed out, taking ownership 10234171129774535356 -> 13814388945268263087

[agilob]

you have qtox already running in background. Looks like OSX bug, to solve it killall qTox?

[fmvin]

macy:Applications mss$ killall qTox
No matching processes belonging to you were found
macy:Applications mss$ pkill qTox
macy:Applications mss$ ./qTox.app/Contents/MacOS/qtox
[15:57:31.484] ../qTox/src/platform/install_osx.cpp:116 : Debug: OS X: Old settings directory not detected
[15:57:31.485] ../qTox/src/persistence/settings.cpp:120 : Debug: "Loading settings from /Users/mss/Library/Application Support/Tox/qtox.ini"
[15:57:31.486] ../qTox/src/ipc.cpp:46 : Debug: Our global IPC ID is  8477703367529022013
[15:57:31.487] ../qTox/src/ipc.cpp:64 : Debug: Attaching to the global shared memory
[15:57:31.487] ../qTox/src/ipc.cpp:259 : Debug: Previous owner timed out, taking ownership 2407741734642051942 -> 8477703367529022013

After reboot the same effect...

[zetok]

@agilob even if qTox was already running, launching it "again" should result in current qTox instance being brought to foreground.

as for killing the process, shouldn't that be killall qtox (lowercase)?

[LittleVulpix]

Something similar just happened to me on my windows machine.

W7 x64 (connected to a domain).

qtox worked there without any issues. When I started it, it said there is an update and that if I wanted to download it. I said yes and used it, but then didn't restart it. Just shut it down and turned off my PC.

Next day I started qtox and it didn't load. The qtox window came up but it was completely empty - white and "not responding". When I closed qtox and tried starting it again,it started just fine! So I closed it and started it once more and this time it froze again.

Basically, when it worked, it complained (in the logs) that it could not lock the profile, but it allowed me to select and load it and it logged me on and connected, no issues. When the profile was "unlocked" however, qtox wouldn't start at all (white window, frozen).

I assume a filesystem-based lock (like *.lck or something) is created to mark the file as locked, but qtox tries and if the file is not actually locked, it loads it just fine and then cleans that lck file - which causes a problem the next time I try to start qtox because it does whatever it does when the profile is not marked as locked.

The qtox version is:

[20:43:20.678] src/main.cpp:143 : Debug: built on: 08:27:59 Jan 22 2016 ( 1453469193 )
[20:43:20.678] src/main.cpp:144 : Debug: commit: d550aa08a2aa7cb644692031684f43209440a1d5

Here's the log from when it freezes:

[20:38:47.047] src/persistence/profile.cpp:86 : Debug: Loading tox save "C:/Users//AppData/Roaming/toxtox_save.tox"
[20:38:47.048] src/persistence/settings.cpp:345 : Debug: "Saving global settings at C:/Users//AppData/Roaming/toxqtox.ini"
[20:38:47.100] src/persistence/settings.cpp:286 : Debug: Loading personnal settings from "C:/Users//AppData/Roaming/tox/tox_save.ini"
[20:38:47.110] src/nexus.cpp:82 : Debug: Starting up
[20:38:47.385] src/core/core.cpp:240 : Debug: Loading user profile
[20:38:47.385] src/persistence/profile.cpp:249 : Debug: Loading tox save "C:/Users//AppData/Roaming/toxtox_save.tox"
[20:38:47.385] src/core/core.cpp:138 : Warning: Core starting with IPv6 disabled. LAN discovery may not work properly.
[20:38:48.246] src/widget/systemtrayicon.cpp:93 : Debug: Using the Qt backend

And here is the log from when I force-terminate it and then start a new one:

[20:43:20.679] src/persistence/profile.cpp:78 : Warning: Failed to lock profile "tox_save"
[20:43:20.679] src/nexus.cpp:82 : Debug: Starting up
[20:43:26.774] src/persistence/profile.cpp:86 : Debug: Loading tox save "C:/Users//AppData/Roaming/toxtox_save.tox"
[20:43:26.775] src/persistence/settings.cpp:345 : Debug: "Saving global settings at C:/Users//AppData/Roaming/toxqtox.ini"
[20:43:26.804] src/persistence/settings.cpp:286 : Debug: Loading personnal settings from "C:/Users//AppData/Roaming/tox/tox_save.ini"
[20:43:26.925] src/core/core.cpp:240 : Debug: Loading user profile
[20:43:26.925] src/persistence/profile.cpp:249 : Debug: Loading tox save "C:/Users//AppData/Roaming/toxtox_save.tox"
[20:43:26.926] src/core/core.cpp:138 : Warning: Core starting with IPv6 disabled. LAN discovery may not work properly.
[20:43:27.823] src/widget/systemtrayicon.cpp:93 : Debug: Using the Qt backend
[20:43:28.139] :0 : Warning: QObject::connect: Cannot connect (null)::stateChanged(QNetworkSession::State) to QNetworkReplyHttpImpl::_q_networkSessionStateChanged(QNetworkSession::State)
[20:43:29.356] src/core/core.cpp:411 : Debug: "Connecting to 194.249.212.109:33445 (fluke571)"
[20:43:29.356] src/core/core.cpp:411 : Debug: "Connecting to 185.25.116.107:33445 (MAH69K)"
[20:43:34.974] src/core/core.cpp:411 : Debug: "Connecting to 144.76.60.215:33445 (sonOfRa)"
[20:43:34.974] src/core/core.cpp:411 : Debug: "Connecting to 23.226.230.47:33445 (stal)"
[20:43:37.418] src/core/core.cpp:378 : Debug: Connected to the DHT
[20:43:37.420] src/persistence/profile.cpp:314 : Debug: Saving tox save to "C:/Users//AppData/Roaming/toxtox_save.tox"
[20:43:56.639] src/core/corefile.cpp:292 : Debug: "Received avatar request 0:65536, accept, since we don't have it in cache."
[20:43:58.519] src/core/corefile.cpp:441 : Debug: Got 46542 bytes of avatar data from 0

Essentially they're the same except this one complains about a locked profile but starts.

[skotopes]

For developers: There is an deadlock when qTox rotates logs. Basically it starts with line 138 in main.cpp, and happens on QDebug instance destruction at the end of section. I haven't done full debugging, but as I can guess that it happens because qTox do logging into file while doing rotation.

For everyone else: just wipe ~/Library/Application Support/Tox/qtox.log

[agilob]

@antis81 ?

[skotopes]

Anyone? ;-)

[ddobrev]

A friend of mine has had this for at least a month and I only discovered this issue - and the workaround 3 comments above - by accident. Could you please make it more prominent, for example by adding a note to the README or wiki, until the problem is fixed?

[skotopes]

@ddobrev No one give a duck. You can fix it by your own, just pull master, and then cherrypick commits from my branch.

[ddobrev]

@skotopes thank you for your reply, and for your workaround too. Fellows, I understand @skotopes needs to make some changes to his PR but could anyone help him do so? This is a serious problem and he has, as far as I can see, already thoroughly researched it and implemented the core fix. I think he only needs a little assistance from anyone familiar with the source and this bug will be over with.

[zetok]

@ddobrev

Fellows, I understand @skotopes needs to make some changes to his PR but could anyone help him do so?

If I actually knew C++, I'd surely help – with that being said, the only thing wrong about the C++ code that I could spot was that it didn't adhere to coding guidelines. Somewhere in the process of fixing that @skotopes broke compiling on travis, at which point it needs to be fixed first before merge.

As for changes to the script – AFAICT they're not needed. @skotopes said that they're needed, which absolutely should not be the case, since there's no way that toxcore/filter_audio would be installed system-wide using bootstrap script.

In other words, there are 2 minor fixes required AFAICT, both of them should be within capabilities of @skotopes. And once fixed, PR can be reviewed & merged by someone who knows C++.

[ddobrev]

the only thing wrong about the C++ code that I could spot was that it didn't adhere to coding guidelines
As for changes to the script – AFAICT they're not needed. @skotopes said that they're needed, which absolutely should not be the case, since there's no way that toxcore/filter_audio would be installed system-wide using bootstrap script.

@skotopes what do you think?

[skotopes]

@skotopes what do you think?

@ddobrev I think I'm lazy. And fat.

As for the topic, travis fails to build linux version because linux got old Qt. I do want to say that I care and want to fix it, but that will be a lie.
As for script, I've modified it to use with brew (which originally was proposed for building mac version of qTox), but as far as I see guys do not want to use brew. I also do want to say that I care and want to fix it, but that also will be a lie.
After all I found that I'm fine with maintaining my own branch and building it from time to time.
Also feel free to use my code to make a new pull request.

[zetok]

As for script, I've modified it to use with brew (which originally was proposed for building mac version of qTox), but as far as I see guys do not want to use brew.

Well, regarding using brew to get toxcore/filter_audio - I don't know how reliable (whether at all) can brew be, or will be in the future to get toxcore/filter_audio. At the same time, building toxcore is relatively "cheap & easy" via script, which results in a situation where toxcore is compiled by qTox script, while (all?) other missing deps are installed via brew.

If there was any guarantee that toxcore from brew will work, it probably would be used instead.

[ddobrev]

A friend hit this bug. He deleted the log and qTox started again but in just a few days it started crashing more and more. My personal guess is that the reason is the gradually growing log file. Since @skotopes has actually fixed the coding style in another commit, if the only remaining problem is the changes to the build script, could you please just ignore them and merge the rest?

[ddobrev]

Thank you very much. I really hope there will be a stable release soon.