--- Log opened Wed Jan 03 00:00:54 2018 00:18 -!- Horwitz [~mich1@p200300800E749E00022268FFFE64E7C4.dip0.t-ipconnect.de] has quit [Ping timeout: 255 seconds] 00:30 -!- Horwitz [~mich1@p200300800E7E5700022268FFFE64E7C4.dip0.t-ipconnect.de] has joined #navit 00:31 -!- mode/#navit [+o Horwitz] by ChanServ 01:35 -!- j_f-f [~quassel@rs-7.jff-webhosting.net] has quit [Ping timeout: 240 seconds] 01:45 -!- j_f-f [~quassel@rs-7.jff-webhosting.net] has joined #navit 05:51 -!- noradtux [~noradtux@port-24484.pppoe.wtnet.de] has quit [Ping timeout: 240 seconds] 05:51 -!- noradtux [~noradtux@2a02:2028:844:b401:ec4:7aff:fe33:3dc1] has joined #navit 05:55 -!- xenos1984 [~xenos1984@2001:bb8:2002:200:6651:6ff:fe53:a120] has joined #navit 10:10 -!- zintor [5a2512f3@gateway/web/freenode/ip.90.37.18.243] has joined #navit 10:10 #navit: < zintor> re4 10:10 #navit: < zintor> well..baby won't fall asleep alone :( 10:11 #navit: < zintor> is it planned to split navit.xml as proposed in https://forum.navit-project.org/viewtopic.php?f=19&t=400 ? 10:12 #navit: < zintor> worth thinking about that again? 10:24 #navit: < zintor> usul set up a wiki page for mapicons: https://wiki.navit-project.org/index.php/User:Usul/MapIconsNG 10:24 #navit: < zintor> youte: could you please have a look at it 10:25 #navit: < zintor> would be nice, if you could adapt it with new icons, or? 10:37 -!- zintor [5a2512f3@gateway/web/freenode/ip.90.37.18.243] has quit [Ping timeout: 260 seconds] 10:59 -!- pini [~pini@bou-fi.pustule.org] has joined #navit 14:40 #navit: < jkoan> Hi zintor 14:41 #navit: < jkoan> I would also like to split the Navit.xml but only on non embedded devices probably. But this should not be really difficult. 15:33 -!- xenos1984 [~xenos1984@2001:bb8:2002:200:6651:6ff:fe53:a120] has quit [Quit: Leaving.] 15:55 -!- xenos1984 [~xenos1984@22-164-191-90.dyn.estpak.ee] has joined #navit 17:00 -!- nuovolnx [~nuovolnx@host80-31-dynamic.33-79-r.retail.telecomitalia.it] has joined #navit 17:01 -!- nuovolnx [~nuovolnx@host80-31-dynamic.33-79-r.retail.telecomitalia.it] has quit [Client Quit] 17:38 #navit: <@KaZeR> hi there 17:51 #navit: <@KaZeR> 268 spam attack on the wiki today. We need to move to readthedocs 17:52 #navit: <@KaZeR> (we also had 120 yesterday) 18:16 -!- mvglasow [~mvglasow@5.90.216.135] has joined #navit 18:17 #navit: <@KaZeR> mvglasow \o/ 18:20 #navit: < mvglasow> hi KaZeR 18:22 #navit: < mvglasow> I hear there's been happy news outside of Navit... 18:26 #navit: <@KaZeR> haha indeed 18:27 #navit: <@KaZeR> it's nice to see you around! 18:27 #navit: < mvglasow> congratulations then... and a Happy New Year! 18:28 #navit: <@KaZeR> thanks, and happy new year to you too :) 18:28 #navit: < mvglasow> thanks 18:29 #navit: < mvglasow> there's been some progress with the traffic module... 18:29 #navit: < mvglasow> crude map matching (i.e. matching a pair of coordinates to the appropriate segments) now works 18:30 #navit: < mvglasow> the latest commit just dumps it to a textfile map (easiest way to visualize it in Navit) 18:30 #navit: <@KaZeR> yeah i've kept an eye on the wiki and your repo. nice! Do you think that we could use a similar technique for other traffic sources like Bing? 18:30 #navit: < mvglasow> right now I'm working on a map provider 18:31 #navit: < mvglasow> in fact, the whole thing is modular, so it should be possible to write a Bing plugin as well 18:31 #navit: < mvglasow> all it would have to do is translate the data into a set of structs 18:32 #navit: < mvglasow> and the traffic module would do the rest, i.e. matching to the map, generating traffic distortions, removing them as messages are cleared or expire 18:32 #navit: < mvglasow> the only obstacle with Bing is that it relies a lot on text descriptions, thus traffic reports may be somewhat crude 18:33 -!- AVIC-MRZ02 [b9e3b688@gateway/web/freenode/ip.185.227.182.136] has joined #navit 18:33 #navit: < mvglasow> as machine parseability is limited 18:34 #navit: < AVIC-MRZ02> Hi there 18:45 #navit: <@KaZeR> mvglasow: indeed. really cool, though 18:45 #navit: <@KaZeR> hey AVIC-MRZ02 18:46 #navit: < mvglasow> I've run into a weird issue in my map provider... 18:46 #navit: < mvglasow> in my implementation of map_rect_create_item() I have the following lines: 18:46 #navit: < mvglasow> struct item_priv * priv_data; 18:47 #navit: < AVIC-MRZ02> Hi KaZeR 18:47 #navit: < mvglasow> priv_data = g_new0(struct item_priv, 1); 18:47 #navit: < mvglasow> and the call to g_new0() segfaults 18:47 #navit: < mvglasow> no idea why... 18:47 #navit: < mvglasow> though the following line works: 18:47 #navit: < mvglasow> ret = g_new0(struct item, 1); 18:48 #navit: < mvglasow> apparently, it's related to the item_priv type 18:49 #navit: < mvglasow> maybe because there are several types of that name 18:49 #navit: < mvglasow> any ideas? 19:00 #navit: < mvglasow> update: I replaced: 19:00 #navit: < mvglasow> priv_data = g_new0(struct item_priv, 1); 19:00 #navit: < mvglasow> with: 19:00 #navit: < mvglasow> priv_data = g_malloc0(sizeof(struct item_priv)); 19:01 #navit: < mvglasow> which seems to work. Weird, but it does the trick 19:01 -!- nuovolnx [~nuovolnx@host80-31-dynamic.33-79-r.retail.telecomitalia.it] has joined #navit 19:02 #navit: <@KaZeR> mmm yeah weird indeed 19:05 -!- nuovolnx [~nuovolnx@host80-31-dynamic.33-79-r.retail.telecomitalia.it] has quit [Client Quit] 19:08 #navit: < mvglasow> it gets weirder: now all of a sudden, the g_malloc0() call segfaults as well 19:09 #navit: <@KaZeR> so it's probably something else :) 19:09 #navit: <@KaZeR> have you tried running it against gdb? 19:10 #navit: < mvglasow> yeah, that's how I got the stack trace 19:10 #navit: < mvglasow> and the weird thing is that the first call to map_rect_create_item() goes through, only the second one fails 19:11 #navit: <@KaZeR> can you share the full stack trace? 19:12 #navit: < mvglasow> here you go: https://pastebin.com/dTKYQUcq 19:13 #navit: < mvglasow> ...err... sorry, that was a different one... 19:14 #navit: < mvglasow> this time, two calls to map_rect_create_item() went through OK, and I got a SIGABRT in map_rect_destroy() 19:14 #navit: < mvglasow> that's what the above stack trace is for 19:15 #navit: < mvglasow> the offending line is: 19:15 #navit: < mvglasow> mr->m->meth.map_rect_destroy(mr->priv); 19:15 #navit: < mvglasow> (map.c:395) 19:15 #navit: < mvglasow> both the method and its argument seem to point to valid data 19:17 #navit: < mvglasow> here's the one with the crash in map_rect_create_item(): https://pastebin.com/erzdDXsC 19:18 #navit: < mvglasow> so apparently it's some kind of spurios behavior... 19:18 #navit: < mvglasow> more often than not, allocating memory fails on the second call 19:19 #navit: < mvglasow> and when it works twice, then map_rect_destroy fails at the second attempt 19:23 #navit: <@KaZeR> ok. can you point me to the relevant code in your github? 19:24 #navit: < mvglasow> https://github.com/mvglasow/navit/blob/traffic/navit/traffic.c 19:25 #navit: < mvglasow> it's the only file I changed for the map provider 19:29 #navit: < mvglasow> afk, back in ~30 min 19:33 #navit: <@KaZeR> well that stack trace is odd. traffic_location_match_to_map() at traffic.c:1,367 0x414036 -> doesn't point to the correct piece of code 19:43 #navit: < mvglasow> line 1367 should be the call to tm_add_item() 19:43 #navit: <@KaZeR> yes, and that's why i find this stack trace odd 19:45 #navit: < mvglasow> why? the next line (above) is tm_add_item() at traffic.c:405 0x4140d8 19:46 #navit: < mvglasow> looks correct to me up to here. or what is it that looks odd to you? 19:52 #navit: <@KaZeR> 405 spam attack on the wiki today, i'm restricting edits. 20:16 -!- AVIC-MRZ02 [b9e3b688@gateway/web/freenode/ip.185.227.182.136] has quit [Quit: Page closed] 21:57 #navit: < mvglasow> I've grabbed the glibc sources and examined the top item in the stack trace (the one where g_new0() segfaults)... 21:58 #navit: < mvglasow> the offending statement is: 21:58 #navit: < mvglasow> bck->fd = unsorted_chunks (av); 21:58 #navit: < mvglasow> apparently bck does not point to a valid memory address 21:59 #navit: < mvglasow> which means we're dealing with corruption of an internal memory structure 21:59 #navit: < mvglasow> of glinc 21:59 #navit: < mvglasow> ^glibc 22:08 #navit: <@KaZeR> that's really odd. i guess that this is on your linux box? 22:08 #navit: <@KaZeR> what would I need to reproduce your tests? 22:09 #navit: < mvglasow> Ubuntu 16.04, all patches applied; glibc version is 2.23 22:10 #navit: < mvglasow> then again, Navit uses g_new0() and g_free() all over the place, so it's kinda odd this appears only here 22:12 #navit: < mvglasow> I wonder if this is being caused by some bug in my code, but I currently have no idea what that could be 22:14 #navit: <@KaZeR> yeah that's why i'd like to try to reproduce. we could even leverage circleci and setup some tests. just need your guidance on how to test :) 22:15 #navit: < mvglasow> that's pretty straightforward: you need the following line in navit.xml: 22:15 #navit: < mvglasow> 22:16 #navit: < mvglasow> (must be a child of navit) 22:16 #navit: < mvglasow> then launch (I am using the GTK GUI, though that shouldn't make a difference) and wait some 2 seconds 22:17 #navit: < mvglasow> you will see some error messages from traffic_* on the console 22:18 #navit: < mvglasow> (I've abused the error log level to make sure certain things always show up, will fix this once the code works) 22:18 #navit: <@KaZeR> we all abuse the error log level at some point :) 22:18 #navit: < mvglasow> :-) 22:18 #navit: < mvglasow> also, Navit will drop a file called distortion.txt in its data dir 22:19 #navit: < mvglasow> when you see these things, the traffic plugin is up and running 22:19 #navit: < mvglasow> you will also need a map of Munich in your mapset, don't know if the supplied one will do; a map of Bavaria should work 22:21 #navit: < mvglasow> Austria should also work (and is a predefined area on the map server) 22:21 #navit: < mvglasow> as for the map_rect_destroy() bug... 22:22 #navit: < mvglasow> map_rect_destroy() somehow calls __GI__libc_free() before calling the map method 22:23 #navit: < mvglasow> and the error is detected by _int_free() 22:24 #navit: < mvglasow> the rest is (intentional) error handling after _int_free() has detected invalid data 22:30 #navit: < mvglasow> and I get the following on the console: 22:30 #navit: < mvglasow> *** Error in `/home/michael/workspaces/navit/navit-linux/navit/navit': free(): invalid next size (fast): 0x0000000000998700 *** 22:32 #navit: < mvglasow> just tested the g_new0() bug by replacing it with a plain malloc(), this segfaults as well at the same statement 22:33 #navit: <@KaZeR> looks like it doesn't crash for me : https://pastebin.com/vQGr7ifi 22:33 #navit: <@KaZeR> i'm using the default map of Munich 22:54 #navit: < mvglasow> looks like only one segment got matched, the rest is probably outside the boundaries of the map 22:55 #navit: < mvglasow> the report for the A9 alone should generate some 25 segments 23:02 #navit: <@KaZeR> ok let me fetch a bigger map 23:08 #navit: < mvglasow> just came across https://stackoverflow.com/questions/1441017/how-can-malloc-cause-a-sigsegv 23:08 #navit: < mvglasow> same issue, a totally innocuous malloc() causing a segfault 23:09 #navit: < mvglasow> the accepted answer is "Check that you are not writing anything beyond the bounds of any previous allocation" 23:09 #navit: < mvglasow> and a comment recommends using valgrind 23:10 #navit: <@KaZeR> "the report for the A0 should generate 25 segments" how should i get that report? 23:10 #navit: < mvglasow> it's hardcoded in the traffic_dummy plugin 23:10 #navit: <@KaZeR> with the map of Austria from our server, i can still create a distortion via the GTK Ui without crash 23:10 #navit: <@KaZeR> ha ok 23:10 #navit: < mvglasow> https://github.com/mvglasow/navit/blob/traffic/navit/traffic/dummy/traffic_dummy.c 23:11 #navit: <@KaZeR> do you get this too? error:navit:event_add_timeout:Can't find event system method add_timeout. Event system is not set. 23:13 #navit: <@KaZeR> the distortion file isn't created if i don't add one manually in the ui 23:13 #navit: < mvglasow> no, not this one 23:14 #navit: < mvglasow> as for the distortion file, you can try creating an empty one and see if it gets filled 23:15 #navit: <@KaZeR> i think that the callback isn't getting called because of this even system issue 23:15 #navit: <@KaZeR> (on my end) 23:16 #navit: < mvglasow> do you get the following line at some point: 23:16 #navit: < mvglasow> error:navit:tm_rect_create_item:enter 23:16 #navit: < mvglasow> ? 23:17 #navit: < mvglasow> that should happen for each segment which gets created 23:18 #navit: < mvglasow> or, if you suspect there's an error on your end, go back to the previous commit 23:18 #navit: < mvglasow> it has no map provider but dumps all segments to a textfile map 23:18 #navit: <@KaZeR> no i am not getting that line 23:18 #navit: < mvglasow> you can examine it manually or ad it to your mapset 23:20 #navit: < mvglasow> then indeed it looks like there's some issue with the event system 23:21 #navit: < mvglasow> do other event-driven things work on your end? 23:21 #navit: <@KaZeR> they do in my other sourcetrees yeah 23:21 #navit: <@KaZeR> that's odd 23:23 #navit: < mvglasow> no idea why this isn't working... it works for me and I didn't touch the event system 23:23 #navit: < mvglasow> all I changed in the existing codebase was adding a few exports, and moving one function from route.c to item.c and exporting it 23:24 #navit: < mvglasow> as well as adding the initialization stuff for the traffic module (as described in the wiki) 23:34 #navit: < mvglasow> I'll look into Valgrind tomorrow. Gotta go, it's getting late here in Europe 23:34 #navit: < mvglasow> I will check the chat logs, just in case 23:34 #navit: < mvglasow> thanks for your help so far 23:35 -!- j_f-f [~quassel@rs-7.jff-webhosting.net] has quit [Ping timeout: 272 seconds] 23:36 #navit: <@KaZeR> no worries. i'm looking into this event issue, it's odd 23:44 -!- xenos1984 [~xenos1984@22-164-191-90.dyn.estpak.ee] has quit [Quit: Leaving.] 23:47 -!- mvglasow [~mvglasow@5.90.216.135] has quit [Quit: Leaving] 23:49 -!- j_f-f [~quassel@rs-7.jff-webhosting.net] has joined #navit --- Log closed Thu Jan 04 00:00:56 2018