lampe-gtk crash: unexpected localtime-format for schedules

[NerosTie]

Since today, when I launch lampe-gtk, I have:

(lampe-gtk:5757): GLib-CRITICAL **: g_strsplit: assertion 'string != NULL' failed
[1]    5757 segmentation fault (core dumped)  lampe-gtk

I have a window then it crashes immediately. If there is no .lamperc or no internet connection, it works.

[poinck]

Did you had a glib-update recently? If so, could you rebuild "lampe" from AUR?

[NerosTie]

Yep, it works now (few days ago it didn't work when I rebuilt it).

[poinck]

I just updated my arch-system without rebuilding "lampe-gtk" and it still works. It seems there is no dependency-checking between the arch-base and the AUR-packages installed.

Maybe I can ask the packager (i am just maintaining the Gentoo-ebuild myself) to optimize the dependencies. I am not sure wether the target-version of glib needs to be 2.42.

[FSMaxB]

I'm not sure which glib version lampe requires, but it currently is 2.48 in arch, so there shouldn't be a problem if the system is even remotely up to date.

To be safe, I'll increase the pkgrel variable in the PKGBUILD to trigger a rebuild.

[NerosTie]

This issue is back (on Arch) :disappointed:

[FSMaxB]

I don't know how to reproduce this problem. Just tried, didn't crash, but I don't have any Hue Lights to test it with.

[NerosTie]

@FSMaxB When it's not configured or if Lampe don't find the Hub, it works.

[poinck]

I retested after pacman -Syu without recompiling "lampe" and it still worked. Restarted the VM and it still worked, recompiled "lampe" and it worked, too.

I need more information to track this. I consider this a bug, because "lampe-gtk" uses too much depricated functions of GTK (issue #33 ). Please leave this issue open, even if your "lampe"-installation starts working again.

[NerosTie]

Your lampe in the VM is configured with a hub?

I can give you the compilation log if it can helps, but it's flooded with warnings about deprecated things.

[poinck]

If you mean by "hub" the Hue bridge, than yes, it is connected. I tested all functions.

Did your bridge/hub received new software lately? I am running the first generation of it and updated it once manually last year. I don't trust it to be connected to the internet all the time, so it never receives any updates. Maybe this Bridge/Hub 2.0 has a slightly different JSON-API. I noticed some mails from Philipps informing me about the new Bridge which has new functions, but "lampe" does not use any of them yet.

Maybe they changed something for existing functions, anyway. One way to find out is to get a new bridge. But you could recompile with make compile_debug. That should give some output on the console during runtime. If you could paste this output here, I can investigate wheter this is a JSON-API issue.

[NerosTie]

Yes, the bridge, sorry.

I have the second generation of the bridge and it is updated to the last version with the Android App. Yes, they are changing things, there is a new "v2" app and a firmware which came at the same time.

Compilation with make compile_debug: https://gist.github.com/NerosTie/85bb834971cad64ef8cab4e01a5eae24

[poinck]

Thx so far, but now I need a runtime-log, too; please start ./lampe-gtk from a terminal.

[NerosTie]

(lampe-gtk:7029): GLib-CRITICAL **: g_strsplit: assertion 'string != NULL' failed
[1]    7029 segmentation fault (core dumped)  lampe-gtk

[poinck]

I expected at least a log that starts with:

[main] start
[LampeRc] found bridgeuser
'bridgeuser='

You could try to remove or move ~/.lamperc somewhere else and reregister at bridge with lampe (the cli-version).

[NerosTie]

This?

(lampe-gtk:9100): Json-CRITICAL **: json_node_get_object: assertion 'JSON_NODE_IS_VALID (node)' failed

(lampe-gtk:9100): Json-CRITICAL **: json_object_get_members: assertion 'object != NULL' failed

(lampe-gtk:9100): Json-CRITICAL **: json_node_get_object: assertion 'JSON_NODE_IS_VALID (node)' failed

(lampe-gtk:9100): Json-CRITICAL **: json_object_get_members: assertion 'object != NULL' failed

[poinck]

No, not exactly, but ..

One thing is for sure, "lampe" does not support the bridge firmware v2 and the trace does not help to fix that. I need to review all the changes they made in this version. Unfortunately I cannot update my bridge to the newest version (not sure wether this is possible). I need a second bridge to develop and test the support for the new firmware.

If you could provide the debug-log by starting ./lampe-gtk from the directory where you built it with compile_debug, that would help to see what JSON-response comes from the bridge. Maybe then I can prevent "lampe-gtk" from crashing. And maybe something will work again.

[NerosTie]

With no .lamperc: https://gist.github.com/NerosTie/158d63ee84e0775788ee796dd462ef7b With a .lamperc: https://gist.github.com/NerosTie/5114a48e89f803805e6d12c005aa9e99

This?

[poinck]

Yes, the second output looks good. I can see that Schedules are the problem. There is something unusual in the localtime-field and strsplit fails. I'll let you know, when I have a new version to test.

It does not look like a real JSON-API change after all, just like something "lampe-gtk" does not support with Schedules. That reminds me, that I wanted to finish the Schedule-feature some time ago.

[poinck]

Here is a possible fix: Can you please test it? In your checked-out repo do:

git fetch
git checkout issue36_schedules_crash 
git pull
make clean
make compile_debug
./lampe-gtk

[NerosTie]

It works :-)

[poinck]

Can you live for a while on this branch? But you can do a sudo make install to have it system-wide. I am not sure when I have time to prepare an official bugfix-release for this.

Thx for testing.

[FSMaxB]

I just updated the AUR package.