完善资料让更多小伙伴认识你,还能领取20积分哦, 立即完善>
当在检查连接的RSSI和噪声的调试器中运行WICDE 60.1代码时,当我取下正在连接的访问点时,我遇到了一个“错误:无效缓冲区”断言的问题。为了确保它不是我正在使用的非常复杂的代码中的一个bug,我使用SNIP.UdpStand复制了这个问题。错误是在WWDIWiFixGEtiOCiTLL BuffER()中[43XXXWi-Fi/WICD/WWD/NET/WWDWiWiF.C]。当返回WSDJTimeUT时,“响应”缓冲区为NULL,但尽管如此,它仍然被释放。它不应该被释放,因为它不存在。
WWDJRESULTTWT WWDWIWIFIGETGETIOCLTL缓冲(UIT32),IUCT8*T*OUTHORD缓冲区,UTI1616T超长,WWDI接口接口 { WICEDED缓冲液缓冲液; UTIT32×T*数据; WieDeff-Fuffelt反应; WWD结果; 数据=(UTI32×T*)WWDJSDPCMGETGETIOIOLTL缓存(缓冲器,OutOthLoad); 校验-缓冲(数据); 结果= WWDJSDPCMysEndoiIOCTL(SDPCMYGET,IOCTL,缓冲器,和响应,接口);/*有任何情况下,当响应为非空时,将返回一个错误?*/ *它工作:将结果复制到输出缓冲区*/ 如果(WWDJ成功==结果) { 数据=(UTI32×T*)HoST.BuffryGETHOL.CurrthyTabeODATA指针(响应); MEMCPY(OutOx缓冲区,数据,OutOthLoad); } HoothBuffelx发布(响应,WWDJNETWorksRx);/*这条线是否只在WWDY成功上执行?*/ 返回结果; } 为了生成这个错误,我对UdpSimult.c进行了一些微小的更改,并使用了WiFixCuffixDCT.h中的CclipTyAppssid和PaspHaseh,然后根据指令构建并运行剪辑。当它运行时,我拔出了接入点。大约过了一分钟,断言发生了。我已经附加了一个复制的UPDPix.c代码的副本。 ZIP邮编 3.5 K 以上来自于百度翻译 以下为原文 When running WICED 6.0.1 code in the debugger that was checking the RSSI and noise of a connection I ran into problems with an "Error: Invalid buffer" assert when I took down the access point to which I was connecting. To make sure it wasn't a bug in the very complicated code that I was working with, I reproduced the problem using snip.udp_transmit. The bug is in wwd_wifi_get_ioctl_buffer() [43xxx_Wi-Fi/WICED/WWD/internal/wwd_wifi.c]. When WWD_TIMEOUT is returned, the "response" buffer is NULL, but it gets released in spite of that. It shouldn't be released, because it doesn't exist. wwd_result_t wwd_wifi_get_ioctl_buffer( uint32_t ioctl, uint8_t* out_buffer, uint16_t out_length, wwd_interface_t interface ) { wiced_buffer_t buffer; uint32_t* data; wiced_buffer_t response; wwd_result_t result; data = (uint32_t*) wwd_sdpcm_get_ioctl_buffer( &buffer, out_length ); CHECK_IOCTL_BUFFER( data ); result = wwd_sdpcm_send_ioctl( SDPCM_GET, ioctl, buffer, &response, interface );/*Are there any cases where an error would be returned where response would be non-NULL?*/ /* it worked: copy the result to the output buffer */ if ( WWD_SUCCESS == result ) { data = (uint32_t*) host_buffer_get_current_piece_data_pointer( response ); memcpy( out_buffer, data, out_length ); } host_buffer_release( response, WWD_NETWORK_RX ); /*Should this line be only executed on WWD_SUCCESS?*/ return result; } To generate this error I made some minor changes to udp_transmit.c and used my CLIENT_AP_SSID & PASSPHRASE in wifi_config_dct.h. Then I built and ran the snip according to the instructions. While it was running I unplugged the access point. After a minute or so the assert occurred. I have attached a copy of the udp_transmit.c code I modified.
|
|
相关推荐
6个回答
|
|
当AP返回时,我可以使用UDPX传输应用程序的修改版本来传输数据。我希望我们的理解在这一部分是一致的。IOCTL失败的实现问题已经被WWDJSDPCMysEnthiIOLL()API调用所关心,但是您接收到的SIGTRAP错误是出于不同的原因。在进入调试模式之前,请做出正确的调试配置设置。
单击Debug配置左左窗口,请选择43XX-Wi-FiDebug GoDOWSwitter到启动页,将下面的指令添加到以下停止区域:添加符号文件Buffel/Eclipse调试软件/LSTSTuxBug。ELF 0x800 0在同一启动页中,清除运行命令区域,默认值类似于PH。RASE“STEPI”切换到公共页面,点击“启动背景”选项 删除SITPI命令应该解决SIGTRAP错误,并且您应该能够调试应用程序。请告诉我们这是否解决不了你的问题。 以上来自于百度翻译 以下为原文 I was able to transmit the data using your modified version of udp_transmit app when the AP came back up. I hope our understandings are aligned tll this part. The implementation issue about ioctl failure is already taken care by the wwd_sdpcm_send_ioctl() API call; but the SIGTRAP error that you are receiving is for a different reason. Please make the proper debug configuration settings before going into debug mode
Removing the stepi command should solve the SIGTRAP error and you should be able to debug your application. Please let us know if this does not solve your issue. |
|
|
|
chm5 发表于 2018-11-8 07:15 如何设置调试器并不重要。如果得到断言,则代码中的逻辑检查失败。在这种情况下,NULL传递给HoSoBuffelyRelasee(),NULL对这个函数的输入无效。解决方案是在WWDWiWiFixGETIOCLDLBuffER()中编写逻辑,这将防止NULL被发送到HoST.BuffelyRelasee()。我的问题是如何最好地做到这一点。如果每次WSDJSDPCMysEndoIIOLL()返回一个不成功的非零结果,则“响应”缓冲区为null,那么当WSDJSDPCMysEnthiIOLL()成功时,您应该只释放该缓冲区。如果存在WSDJSDPCMysEnthiIOCL()将返回不成功的非零结果以及部分“响应”缓冲区,则无法释放该部分缓冲区将是内存泄漏。 我认为最好的解决办法是在WSDJSDPCMsEnthixIOLL()成功时,总是释放“响应”,但是当它不成功时,只释放“响应”,如果它是非空的。 以上来自于百度翻译 以下为原文 It doesn't matter how you have your debugger set up. If you get an assert there is a logical check that has failed in the code. In this case a NULL was passed to host_buffer_release() and NULL is invalid input to this function. The solution is to write logic in wwd_wifi_get_ioctl_buffer() that will prevent NULL from ever being sent to host_buffer_release(). My questions are about how best to do that. If every time wwd_sdpcm_send_ioctl() returns an unsuccessful non-zero result the "response" buffer is NULL, then you should only release that buffer when wwd_sdpcm_send_ioctl() is successful. If there are cases where wwd_sdpcm_send_ioctl() would return an unsuccessful, non-zero result along with a partial "response" buffer, then failing to release that partial buffer would be a memory leak. I think the best solution is to always release "response" when wwd_sdpcm_send_ioctl() is successful, but when it is unsuccessful only release "response" if it is non NULL. |
|
|
|
billow33 发表于 2018-11-8 07:22 你的报告对我来说很清楚。 (这是一个回归,因为老SDK没有这样的问题)。 以上来自于百度翻译 以下为原文 Your report is very clear to me. (It's a regression because older sdk does not has such issue). |
|
|
|
我查看了43XXXYW-FI/WICD/WWD/NET/WWDWiFi.c的其他情况,其中WSDJSDPCMysEnthiIOCL()返回了一个响应缓冲区,并且发现了两个相同的问题:
WWDWiWiFig GETIOVALIONBUFER() WSDDMESHYSTATUS() 此外,存在内存泄漏,其中响应缓冲区由WWDYSDPCMysEnthiIOLL()分配,并搜索ID。当发现ID时,缓冲区被释放,但在未找到缓冲区的情况下,响应缓冲区不会被释放。见: WWDIWiFixGET-PayTeP.FielTy.Maskyand AdType() 以上来自于百度翻译 以下为原文 I looked through the rest of 43xxx_Wi-Fi/WICED/WWD/internal/wwd_wifi.c for other cases where wwd_sdpcm_send_ioctl() returns a response buffer and I found two more cases of the same problem in: wwd_wifi_get_iovar_buffer() wwd_mesh_status() In addition there is a memory leak where the response buffer is allocated by wwd_sdpcm_send_ioctl() and searched for an ID. When the ID is found the buffer is released, but in the event that the buffer is not found, the response buffer does not get released. See: wwd_wifi_get_packet_filter_mask_and_pattern() |
|
|
|
billow33 发表于 2018-11-8 08:00 谢谢你通知我们。我们正在对这些问题进行内部评估,并提出了同样的罚单。这个问题应该在即将发布的WICE Studio(最有可能的6.2)中得到解决。 以上来自于百度翻译 以下为原文 Thanks for bringing it to our notice. We are evaluating these issues internally and raised a ticket for the same. This issue should be resolved in the upcoming release of WICED Studio (6.2 most likely). |
|
|
|
chm5 发表于 2018-11-8 08:07 Raktim Roy写道: 谢谢你通知我们。我们正在对这些问题进行内部评估,并提出了同样的罚单。这个问题应该在即将发布的WICE Studio(最有可能的6.2)中得到解决。 FKI,SDK-61不包括FIX。 以上来自于百度翻译 以下为原文 Raktim Roy wrote:FYI, sdk-6.1 does not include the fix. |
|
|
|
只有小组成员才能发言,加入小组>>
752个成员聚集在这个小组
加入小组2081 浏览 1 评论
1833 浏览 1 评论
3648 浏览 1 评论
请问可以直接使用来自FX2LP固件的端点向主机FIFO写入数据吗?
1773 浏览 6 评论
1520 浏览 1 评论
CY8C4025LQI在程序中调用函数,通过示波器观察SCL引脚波形,无法将pin0.4(SCL)下拉是什么原因导致?
529浏览 2评论
CYUSB3065焊接到USB3.0 TYPE-B口的焊接触点就无法使用是什么原因导致的?
384浏览 2评论
CX3连接Camera修改分辨率之后,播放器无法播出camera的画面怎么解决?
421浏览 2评论
367浏览 2评论
使用stm32+cyw43438 wifi驱动whd,WHD驱动固件加载失败的原因?
878浏览 2评论
小黑屋| 手机版| Archiver| 电子发烧友 ( 湘ICP备2023018690号 )
GMT+8, 2024-12-2 15:21 , Processed in 1.125177 second(s), Total 88, Slave 72 queries .
Powered by 电子发烧友网
© 2015 bbs.elecfans.com
关注我们的微信
下载发烧友APP
电子发烧友观察
版权所有 © 湖南华秋数字科技有限公司
电子发烧友 (电路图) 湘公网安备 43011202000918 号 电信与信息服务业务经营许可证:合字B2-20210191 工商网监 湘ICP备2023018690号