Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fsotdld crashes on changing networkinterface #1

Open
jake42 opened this issue Apr 2, 2015 · 2 comments
Open

fsotdld crashes on changing networkinterface #1

jake42 opened this issue Apr 2, 2015 · 2 comments
Assignees

Comments

@jake42
Copy link

jake42 commented Apr 2, 2015

fsotdld crashes when changing networkinterfaces, e.g ppp0 goes down. Here is a backtrace with gdb with SHR (e.g. StagingTest 140) on gta04. Also crashes with gta02, thougn no backtrace as it got too slow with gdb.

This is with srv rev: 12843f0
Issue in SHR: http://shr-project.org/trac/ticket/2110

#0  0xb6d48764 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1  0xb6d4c23c in __GI_abort () at abort.c:89
#2  0xb6d80320 in __libc_message (do_abort=<optimized out>, fmt=0xb6e3686c "*** Error in `%s': %s: 0x%s ***\n") at ../sysdeps/posix/libc_fatal.c:175
#3  0xb6d8ad28 in malloc_printerr (action=3, str=0xb6e36980 "munmap_chunk(): invalid pointer", ptr=<optimized out>) at malloc.c:4895
#4  0xb6e9bc00 in g_free (mem=<optimized out>) at gmem.c:252
#5  0xb6e83754 in g_hash_table_remove_all_nodes (hash_table=0xb60024a8, notify=-1226610580) at ghash.c:500
#6  0xb6e84128 in g_hash_table_unref (hash_table=0xb60024a8) at ghash.c:1026
#7  0xb6fafbd4 in fso_framework_base_netlink_notifier_handleMessage (self=0x26738, type=<optimized out>, obj=<optimized out>) at netlinknotifier.c:532
#8  0xb6b3d286 in parse_cb (obj=<optimized out>, p=<optimized out>) at msg.c:721
#9  0xb6b53ab8 in addr_msg_parser (ops=<optimized out>, who=<optimized out>, nlh=<optimized out>, pp=0xbefff5a0) at route/addr.c:316
#10 0xb6b3b422 in nl_cache_parse (ops=ops@entry=0xb6b7119c <rtnl_addr_ops>, who=who@entry=0x0, nlh=0x35500, params=params@entry=0xbefff5a0) at cache.c:905
#11 0xb6b3e31e in nl_msg_parse (msg=msg@entry=0x35340, cb=<optimized out>, arg=arg@entry=0x13120) at msg.c:744
#12 0xb6faef5a in fso_framework_base_netlink_notifier_handleNetlinkMessage (self=0x26738, msg=0x35340) at netlinknotifier.c:387
#13 0xb6b3eed0 in nl_cb_call (msg=0x35340, type=0, cb=0x2ab00) at ../include/netlink-private/netlink.h:129
#14 recvmsgs (cb=0x2ab00, sk=0x2ab78) at nl.c:904
#15 nl_recvmsgs_report (sk=0x2ab78, cb=0x2ab00) at nl.c:955
#16 0xb6b3f126 in nl_recvmsgs (sk=<optimized out>, cb=<optimized out>) at nl.c:979
#17 0xb6b3f132 in nl_recvmsgs_default (sk=<optimized out>) at nl.c:993
#18 0xb6faee56 in fso_framework_base_netlink_notifier_onActionFromSocket (self=0x26738, source=0x2ac28, condition=<optimized out>) at netlinknotifier.c:325
#19 0xb6eda988 in g_io_unix_dispatch (source=0x31dc8, callback=0xb6faef11 <_fso_framework_base_netlink_notifier_onActionFromSocket_gio_func>, user_data=0x26738) at giounix.c:167
#20 0xb6e95d50 in g_main_dispatch (context=0x1de40) at gmain.c:3054
#21 g_main_context_dispatch (context=context@entry=0x1de40) at gmain.c:3630
#22 0xb6e960dc in g_main_context_iterate (context=0x1de40, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3701
#23 0xb6e96598 in g_main_loop_run (loop=0x2f5a8) at gmain.c:3895
#24 0x00008df0 in _vala_main (args=0xbefff8a4, args_length1=1) at main.c:215
#25 0xb6d3327c in __libc_start_main (main=0xbefff8a4, argc=-1226522624, argv=0xb6d3327c <__libc_start_main+276>, init=<optimized out>, fini=0x8e7c <__libc_csu_fini>, rtld_fini=0xb6fe7c08 <_dl_fini>, stack_end=0xbefff8a4) at libc-start.c:269
#26 0x00008ae0 in _start () at ../ports/sysdeps/arm/start.S:124
@mickeyl
Copy link
Member

mickeyl commented Apr 2, 2015

This is quite strange. The crash actually occurs in libfsobasics, namely
protected void handleMessage( uint16 type, Netlink.Object obj )
From the look of it I would expect that all running fsodaemons should actually crash in that case, not just fsotdld. fsotdld not even registers a netlink notification handler with libfsobasics. Perhaps there is some new/unknown netlink message coming in due to the change in network interfaces. I can reproduce this quite easily and will take a look.

@mickeyl mickeyl self-assigned this Apr 2, 2015
@mickeyl
Copy link
Member

mickeyl commented Apr 4, 2015

This is a problem in vala's libnl-3.0.vapi. There is at least one unowned missing, i.e. line 46 states:
public string get_label ();. The underlying API returns a char*, so it needs to be bound as unowned. I will fix this directly in vala and also commit a workaround for us.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants