[jira] [Commented] (MYNEWT-649) "newt target set" allows random variable to be set; should allow only valid variable settings.

2017-05-25 Thread Wanda Chiu (JIRA)

[ 
https://issues.apache.org/jira/browse/MYNEWT-649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16025702#comment-16025702
 ] 

Wanda Chiu commented on MYNEWT-649:
---

Discuss with Aditi and decided newt vals command does not need to support 
variables: syscfg, loader, aflags, cflags, lflags.

PR to validate the variables is: 
https://github.com/apache/incubator-mynewt-newt/pull/65.  



> "newt target set" allows random variable to be set; should allow only valid 
> variable settings.
> --
>
> Key: MYNEWT-649
> URL: https://issues.apache.org/jira/browse/MYNEWT-649
> Project: Mynewt
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>Reporter: Aditi Hilbert
>Assignee: Wanda Chiu
> Fix For: v1_1_0_rel
>
>
> The "newt target set" command should have a check for allowed settings.
> For example, I can set the variable "bogus" with a value and  target.bogus 
> will be added to the target.yml file.   Do we have a list of all the valid 
> variables so we can add the validation to the command?  What I have listed as 
> valid variables in the `newt target set" command documentation are: app, bsp, 
> loader, build_profile, cflags, aflags, lflags, syscfg. 
> We should make sure the "newt vals" command also covers this set of valid 
> target variables to make things consistent.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (MYNEWT-640) Add an newt target "append" feature to change or append target variable values

2017-05-25 Thread Wanda Chiu (JIRA)

[ 
https://issues.apache.org/jira/browse/MYNEWT-640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16025682#comment-16025682
 ] 

Wanda Chiu commented on MYNEWT-640:
---

Closed the previous PR. Open this one:
https://github.com/apache/incubator-mynewt-newt/pull/64

Added the *newt target amend* command to add, change, or delete values for 
multi-value target variables, such as syscfg, cflags etc. It supports the -d 
flag to delete values. 
This addresses concerns raised in MYNEWT-543

> Add an newt target "append"  feature to change or append target variable 
> values
> ---
>
> Key: MYNEWT-640
> URL: https://issues.apache.org/jira/browse/MYNEWT-640
> Project: Mynewt
>  Issue Type: Improvement
>  Security Level: Public(Viewable by anyone) 
>Affects Versions: v1_0_0_beta2
>Reporter: Wanda Chiu
>Assignee: Wanda Chiu
>Priority: Minor
> Fix For: v1_1_0_rel
>
>
> This is a feature enhancement request (for post 1.0) to support an "append" 
> feature that allows a user to change or append to current target variable 
> values:
> The *newt target  set* sets a variable value with the value 
> specified in the command. It overrides the variable's previous values.  For 
> example, the eventq_nordic target has the follow syscfg.yml content:
> {code}
> ### Package: targets/eventq_nordic
> syscfg.vals:
> CONFIG_NEWTMGR: 1
> LOG_NEWTMGR: 1
> SHELL_TASK: 1
> {code}
> Run *newt target set eventq_nordic syscfg=LOG_NEWTMGR=0* and the syscfg.yml 
> file changes to:
> {code}
> ### Package: targets/eventq_nordic
> syscfg.vals:
> LOG_NEWTMGR: 0
> {code}
> Currently users can't  append or change specific values for a variable and 
> without overriding all values.  This support would be useful for target 
> variables other than the *syscfg* variable, e.g *cflags*, *lflags*, etc
> (See MYNEWT-543)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Comment Edited] (MYNEWT-765) os_mbuf memory corruption on native platform

2017-05-25 Thread Christopher Collins (JIRA)

[ 
https://issues.apache.org/jira/browse/MYNEWT-765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16025576#comment-16025576
 ] 

Christopher Collins edited comment on MYNEWT-765 at 5/26/17 12:52 AM:
--

In addition, the double free issue 
(https://github.com/apache/incubator-mynewt-core/pull/292) was causing a 
problem.  After merging that PR, everything looks good to me.

I am going to merge the above PR now.  If you test this again, be sure to grab 
the latest from master.


was (Author: ccollins476):
Looks like I spoke too soon - I'm seeing another issue after letting it run for 
several minutes:
{noformat}
(gdb) p ble_hci_uart_acl_pool
$4 = {mp_block_size = 292, mp_num_blocks = 1000, mp_num_free = -1467022310, 
mp_min_free = 983, mp_membuf_addr = 1290240, mp_list = {stqe_next = 0xc0be0 
}, {slh_first = 0x13b248}, name = 0x3d0a1 
"ble_hci_uart_acl_pool"}
{noformat}

{{mp_num_free}} shouldn't be negative!  I am going to keep looking at this.  
Hopefully this and the memory corruption issue are related.

(The issues I mentioned in the above comment are still valid.)

> os_mbuf memory corruption on native platform
> 
>
> Key: MYNEWT-765
> URL: https://issues.apache.org/jira/browse/MYNEWT-765
> Project: Mynewt
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
> Environment: bsncent app on native 32-bit Ubuntu 17.04
>Reporter: Michał Narajowski
>Priority: Minor
>
> h4. General description:
> There is a segmentation fault error in function {{ble_hs_log_mbuf}} in file 
> {{net/nimble/host/src/ble_hs_log.c}} when receiving notifications at high 
> rate. Tested using *bsncent* app from 
> https://github.com/rymanluk/incubator-mynewt-core/tree/bsn and *bsnprph* also 
> from https://github.com/apache/incubator-mynewt-core/tree/bsnbranch
> Data from HCI command overwrites the os_mbuf struct instead of being written 
> to {{om->om_data}}. I tried to catch that memory violation earlier in code, 
> but somehow it is only triggered in the {{ble_hs_log_mbuf}} function.
> h4. How to reproduce:
> 1. Build and flash *bsnprph* app from 
> https://github.com/apache/incubator-mynewt-core/tree/bsnbranch with the 
> following configuration:
> {quote}
> app=@apache-mynewt-core/apps/bsnprph
> bsp=@apache-mynewt-core/hw/bsp/nrf52dk
> build_profile=optimized
> {quote}
> 2. Build *bsncent* app from 
> https://github.com/rymanluk/incubator-mynewt-core/tree/bsn with the following 
> configuration:
> {quote}
> app=@apache-mynewt-core/apps/bsncent
> bsp=@apache-mynewt-core/hw/bsp/native
> build_profile=debug
> syscfg=BLE_HS_DEBUG=1:BLE_MAX_CONNECTIONS=5:BLE_SM_BONDING=1:BLE_SM_IO_CAP=BLE_HS_IO_KEYBOARD_DISPLAY:BLE_SM_LEGACY=1:BLE_SM_MITM=1:BLE_SM_OUR_KEY_DIST=7:BLE_SM_SC=1:BLE_SOCK_LINUX_DEV=0:BLE_SOCK_USE_LINUX_BLUE=1:BLE_SOCK_USE_TCP=0:LOG_LEVEL=0:MCU_NATIVE_USE_SIGNALS=1:OS_MAIN_STACK_SIZE=512:SHELL_TASK=1
> {quote}
> 3. It is possible to reproduce it using Mynewt controller (but then another 
> issue shows up sometimes, described below) or some other controller like PTS 
> with some hacks in ble_hs_startup.c to start controller.
> 4. Run *bsncent* app from 32bit Ubuntu
> Here is the backtrace from GDB:
> {quote}
> Program received signal SIGSEGV, Segmentation fault.
> __memcpy_sse2_unaligned () at 
> ../sysdeps/i386/i686/multiarch/memcpy-sse2-unaligned.S:651
> 651 ../sysdeps/i386/i686/multiarch/memcpy-sse2-unaligned.S: No such file 
> or directory.
> (gdb) bt
> #0  __memcpy_sse2_unaligned () at 
> ../sysdeps/i386/i686/multiarch/memcpy-sse2-unaligned.S:651
> #1  0x80009fc0 in os_mbuf_copydata (m=0x8008fb6c, off=0, len=1, 
> dst=0x800746c7 ) at 
> repos/apache-mynewt-core/kernel/os/src/os_mbuf.c:722
> #2  0x8001fb5a in ble_hs_log_mbuf (om=0x8008fb6c)
> at repos/apache-mynewt-core/net/nimble/host/src/ble_hs_log.c:32
> #3  0x8001f18c in ble_hs_hci_evt_acl_process (om=0x8008fb6c)
> at repos/apache-mynewt-core/net/nimble/host/src/ble_hs_hci_evt.c:631
> #4  0x80018c1f in ble_hs_process_rx_data_queue ()
> at repos/apache-mynewt-core/net/nimble/host/src/ble_hs.c:195
> #5  0x80019020 in ble_hs_event_data (ev=0x80075aec )
> at repos/apache-mynewt-core/net/nimble/host/src/ble_hs.c:379
> #6  0x80007009 in os_eventq_run (evq=0x80074908 )
> at repos/apache-mynewt-core/kernel/os/src/os_eventq.c:172
> #7  0x80002308 in main (argc=0, argv=0x0) at 
> repos/apache-mynewt-core/apps/bsncent/src/main.c:457
> {quote}
> h4. Another issue
> Actually, there is also a second problem. When using *blehci* as the 
> controller the communication between central and peripheral freezes somewhere 
> around GATT discovery most of the time. It happens quiet randomly. 
> To reproduce it:
> 1. Build and flash *blehci* app from 
> 

[jira] [Comment Edited] (MYNEWT-765) os_mbuf memory corruption on native platform

2017-05-25 Thread Christopher Collins (JIRA)

[ 
https://issues.apache.org/jira/browse/MYNEWT-765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16025576#comment-16025576
 ] 

Christopher Collins edited comment on MYNEWT-765 at 5/26/17 12:02 AM:
--

Looks like I spoke too soon - I'm seeing another issue after letting it run for 
several minutes:
{noformat}
(gdb) p ble_hci_uart_acl_pool
$4 = {mp_block_size = 292, mp_num_blocks = 1000, mp_num_free = -1467022310, 
mp_min_free = 983, mp_membuf_addr = 1290240, mp_list = {stqe_next = 0xc0be0 
}, {slh_first = 0x13b248}, name = 0x3d0a1 
"ble_hci_uart_acl_pool"}
{noformat}

{{mp_num_free}} shouldn't be negative!  I am going to keep looking at this.  
Hopefully this and the memory corruption issue are related.

(The issues I mentioned in the above comment are still valid.)


was (Author: ccollins476):
Looks like I spoke too soon - I'm seeing another issue after letting it run for 
several minutes:
```
(gdb) p ble_hci_uart_acl_pool
$4 = {mp_block_size = 292, mp_num_blocks = 1000, mp_num_free = -1467022310, 
mp_min_free = 983, mp_membuf_addr = 1290240, mp_list = {stqe_next = 0xc0be0 
}, {slh_first = 0x13b248}, name = 0x3d0a1 
"ble_hci_uart_acl_pool"}
```

`mp_num_free` shouldn't be negative!  I am going to keep looking at this.  
Hopefully this and the memory corruption issue are related.

(The issues I mentioned in the above comment are still valid.)

> os_mbuf memory corruption on native platform
> 
>
> Key: MYNEWT-765
> URL: https://issues.apache.org/jira/browse/MYNEWT-765
> Project: Mynewt
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
> Environment: bsncent app on native 32-bit Ubuntu 17.04
>Reporter: Michał Narajowski
>Priority: Minor
>
> h4. General description:
> There is a segmentation fault error in function {{ble_hs_log_mbuf}} in file 
> {{net/nimble/host/src/ble_hs_log.c}} when receiving notifications at high 
> rate. Tested using *bsncent* app from 
> https://github.com/rymanluk/incubator-mynewt-core/tree/bsn and *bsnprph* also 
> from https://github.com/apache/incubator-mynewt-core/tree/bsnbranch
> Data from HCI command overwrites the os_mbuf struct instead of being written 
> to {{om->om_data}}. I tried to catch that memory violation earlier in code, 
> but somehow it is only triggered in the {{ble_hs_log_mbuf}} function.
> h4. How to reproduce:
> 1. Build and flash *bsnprph* app from 
> https://github.com/apache/incubator-mynewt-core/tree/bsnbranch with the 
> following configuration:
> {quote}
> app=@apache-mynewt-core/apps/bsnprph
> bsp=@apache-mynewt-core/hw/bsp/nrf52dk
> build_profile=optimized
> {quote}
> 2. Build *bsncent* app from 
> https://github.com/rymanluk/incubator-mynewt-core/tree/bsn with the following 
> configuration:
> {quote}
> app=@apache-mynewt-core/apps/bsncent
> bsp=@apache-mynewt-core/hw/bsp/native
> build_profile=debug
> syscfg=BLE_HS_DEBUG=1:BLE_MAX_CONNECTIONS=5:BLE_SM_BONDING=1:BLE_SM_IO_CAP=BLE_HS_IO_KEYBOARD_DISPLAY:BLE_SM_LEGACY=1:BLE_SM_MITM=1:BLE_SM_OUR_KEY_DIST=7:BLE_SM_SC=1:BLE_SOCK_LINUX_DEV=0:BLE_SOCK_USE_LINUX_BLUE=1:BLE_SOCK_USE_TCP=0:LOG_LEVEL=0:MCU_NATIVE_USE_SIGNALS=1:OS_MAIN_STACK_SIZE=512:SHELL_TASK=1
> {quote}
> 3. It is possible to reproduce it using Mynewt controller (but then another 
> issue shows up sometimes, described below) or some other controller like PTS 
> with some hacks in ble_hs_startup.c to start controller.
> 4. Run *bsncent* app from 32bit Ubuntu
> Here is the backtrace from GDB:
> {quote}
> Program received signal SIGSEGV, Segmentation fault.
> __memcpy_sse2_unaligned () at 
> ../sysdeps/i386/i686/multiarch/memcpy-sse2-unaligned.S:651
> 651 ../sysdeps/i386/i686/multiarch/memcpy-sse2-unaligned.S: No such file 
> or directory.
> (gdb) bt
> #0  __memcpy_sse2_unaligned () at 
> ../sysdeps/i386/i686/multiarch/memcpy-sse2-unaligned.S:651
> #1  0x80009fc0 in os_mbuf_copydata (m=0x8008fb6c, off=0, len=1, 
> dst=0x800746c7 ) at 
> repos/apache-mynewt-core/kernel/os/src/os_mbuf.c:722
> #2  0x8001fb5a in ble_hs_log_mbuf (om=0x8008fb6c)
> at repos/apache-mynewt-core/net/nimble/host/src/ble_hs_log.c:32
> #3  0x8001f18c in ble_hs_hci_evt_acl_process (om=0x8008fb6c)
> at repos/apache-mynewt-core/net/nimble/host/src/ble_hs_hci_evt.c:631
> #4  0x80018c1f in ble_hs_process_rx_data_queue ()
> at repos/apache-mynewt-core/net/nimble/host/src/ble_hs.c:195
> #5  0x80019020 in ble_hs_event_data (ev=0x80075aec )
> at repos/apache-mynewt-core/net/nimble/host/src/ble_hs.c:379
> #6  0x80007009 in os_eventq_run (evq=0x80074908 )
> at repos/apache-mynewt-core/kernel/os/src/os_eventq.c:172
> #7  0x80002308 in main (argc=0, argv=0x0) at 
> repos/apache-mynewt-core/apps/bsncent/src/main.c:457
> {quote}
> h4. Another issue
> Actually, there is also a second