Closed jvermillard closed 10 years ago
Hi Julien,
Do you have the latest version of liblwm2m ? I ask because the offending memcpy in er-coap-13.c in on line 691 now. I fixed several potential segfault issues related to location_path recently.
Anyway, I'll rerun tests on my side.
I'm at this commit: commit 9f6389e70fc210f78b17b7e4135821e70f722f8c Author: dnav david.navarro@intel.com Date: Tue Apr 8 11:34:02 2014 +0200
Remove useless and potential buggy free
This is the right commit. It was me who was on an old one...
I've got similar segfault on first server response. Server was trying to send 9 bytes: [0x60 41 00 00 82 72 64 01]. Client entered in "coap_parse_message", case COAP_OPTION_LOCATION_PATH, and got segfault in "coap_merge_multi_option" call. I've resolved this by setting tmp_len and tmp_buf (from the case COAP_OPTION_LOCATION_PATH) to 0. tmp_len is checked for 0 inside "coap_merge_multi_option", but my compiler didn't initialize it to 0 by default.
Thank you for spotting this. I just pushed a commit to fix it.
(/me goes and changes his compiler default settings)
When I run lwm2mclient vs leshan, I have this segfault:
± > valgrind ./lwm2mclient 18:47 ==27702== Memcheck, a memory error detector ==27702== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. ==27702== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info ==27702== Command: ./lwm2mclient ==27702==