Build 2016上一些令人兴奋的东西

最新推荐文章于 2024-06-17 11:32:08 发布
转载 最新推荐文章于 2024-06-17 11:32:08 发布 · 191 阅读 · 0 ·
CC 4.0 BY-SA版权
原文链接：http://www.cnblogs.com/risk/p/5365692.html
文章标签：

#移动开发 #嵌入式

在Build2016大会上，微软宣布收购Xamarin，并将其免费集成到Visual Studio 2015 Update 2中，允许开发者使用.NET跨平台开发Android和iOS应用。只需下载更新补丁，VS2015社区版亦可享受此功能。

　　本来应该要更新Windows IOT开发入门的，但是由于Build 2016刚刚过去，不得不将一些令人兴奋的东西给大家进行分享。

首先对于错过这次直播的，可以在以下链接再次看到观看：

https://channel9.msdn.com/Events/Build/2016

整个Build2016个人最兴奋莫过于：xamarin被微软收了，在vs集成中并且免费，免费，免费拉（听说重要的事情要说3遍）

扫盲一下：xamarin是一个可以使用.NET开发Android和IOS应用的东东。

以下是免费版本的具体信息

  • Xamarin Studio 5.10.3.51

  • Xamarin for Visual Studio 4.0.3.214

  • Xamarin.iOS 9.6.1.9 

  • Xamarin.Android 6.0.3.5

  • Xamarin.Mac 2.4.2.1

  • Mono Framework 4.2.2.30

简单理解，只需要下载vs2015 update 2补丁即可体验，对的没错，就是这么简单。同时vs2015社区版也能够享受这个功能。

vs2015 with update 2下载地址：ed2k://|file|cn_visual_studio_enterprise_2015_with_update_2_x86_x64_dvd_8510289.iso|7633639424|E0AFC01631C37BD3046EDBBC30FAB8CC|/

vs2015社区版下载地址：http://download.microsoft.com/download/0/f/8/0f89c8af-9430-4c13-bf6a-d75b7513ac29/vs2015.2.com_chs.iso

 

当然我们也可以不下载vs2015 update 2，而是下载 xamrin studio

 

还有一个个人比较佩服的是

盲人程序员发明“看得见”眼睛，很牛。

视频：http://video.sina.com.cn/view/250536915.html

 

转载于:https://www.cnblogs.com/risk/p/5365692.html

ancihui4398
关注
【QQ机器人搭建】手把手教你使用Python实时监测QQ群消息
吴秋霖的博客
10-26 1万+
手把手教你使用Python实时监测QQ群消息！在数据的基础上做统计、分析与用户画像
史上最全wireshark使用教程，8万字整理总结，建议先收藏再耐心研读
孙叫兽的博客
07-14 3万+
目录 第1章介绍... 1 1.1.什么是Wireshark. 1 1.1.1.主要应用... 1 1.1.2.特性... 1 1.1.3.捕捉多种网络接口... 2 1.1.4.支持多种其它程序捕捉的文件... 2 1.1.5.支持多格式输出... 2 1.1.6.对多种协议解码提供支持... 2 1.1.7.开源软件... 2 1.1.8.Wireshark不能做的事... 2 1.2.系通需求... 2 1.2.1.一般说明... 2 ...
linux视频分享（台湾陪亚4cd）
weixin_34212189的博客
07-07 3236
linux视频分享（台湾陪亚4cd） 希望大家能够分流下载啊。。。 ed2k://|file|%5B%E5%8F%B0%E6%B9%BE%E5%9F%B9%E4%BA%9A%5D%5Blinux%E8%A7%86%E9%A2%91(4CD)%5D.rar|405944463|cc0effa70883e899a5555a7ccb72932c|/ 转载于:...
各资源下载地址整理
热门推荐
zpsos520的博客
03-13 8万+
redhat6.4:  ed2k://|file|[%E7%BA%A2%E5%B8%BD%E4%BC%81%E4%B8%9ALinux.6.4.%E6%9C%8D%E5%8A%A1%E5%99%A8%E7%89%88].rhel-server-6.4-x86_64-dvd[ED2000.COM].iso|3720347648|542c0277eff8b86b7f0c18358df84702|h=
各种链接
tang285377470的专栏
11-04 4万+
office visio 2010 Premium<br />64位简体中文<br />ed2k://|file|cn_visio_2010_x64_516562.exe|515232976|E07BBD0AE55934A8557CB47ACB10D0CE|/<br /><br />32位简体中文<br />ed2k://|file|cn_visio_2010_x86_51664 541.exe|462636136|936EFC78D981A30C87473303E00DC78A|/<br /><br /
ED2K.zip
10-12
ED2K.zip
最近，看了一个新片子，很不错。介绍给大家。
cpongo5
04-08 6571
中文名称：越狱 第一季英文名称：Prison Break Season1资源类型：RMVB版本：[风软FRM字幕组出品]更新第18集泄露版(缺17)发行时间：2005年08月29日导演：Brett Ratner演员：Wentworth Miller .... Michael　　　Dominic Purcell .... Lincoln　　　Robin Tunney .....
【virtualenv】记录Mac上一次令人无语的python virtual environment安装
fernan的博客
10-11 1219
首先用sudo /usr/bin/easy_install virtualenv时，报了错： File "build/bdist.macosx-10.15-x86_64/egg/zipp.py", line 240 def open(self, mode='r', *args, pwd=None, **kwargs): ^ SyntaxError: invalid syntax zip_safe flag n...
『大模型笔记』Cohere的联合创始人Nick Frosst谈：AGI真的只是幻想吗？
AI新视界
06-17 415
AGI（通用人工智能）的立场技术应用和现实世界问题Cohere公司及其活动Command-R模型及其功能检索增强生成（RAG）创始团队的背景工具使用的演变哲学探讨建设日活动开发者指导数据获取和准备多语言支持数据科学与软件工程的角色模型的未来发展技术成熟度和基准测试开源工具包。
【UVM实战】第五章：UVM验证平台的运行（1）phase机制（上）
悟已往之不谏 知来者之可追
02-24 843
UVM实战之phase机制（上）
ED2K资源信息
08-04
ED2K资源信息
韩顺平老师所有视频下载种子，绝不骗人
04-04
包含韩顺平老师所有视频下载种子，只限学习交流
常用网址
宏伟
12-23 1239
1、图标：https://www.iconfont.cn/
emule windows 8 all
03-05 2万+
ed2k://|file|cn_windows_8_x64_dvd_915407.iso|3652950016|5C7F8C212BD3A1827866563773A431C2|/ ed2k://|file|cn_windows_8_x86_dvd_915414.iso|2679801856|9AF10141BFD61BC66D9D6459758D7749|/ ed2k://|file|cn_wi...
电子书
Hackingwu's coding house
02-20 1792
groovy for dynamic special language ed2k://|file|Groovy%20for%20Domain-Specific%20Languages.pdf|3438870|d9377ff2e520a7bdbdf771f7bd9f150f|h=gl5dzduyejenmxwftrqyjzydonwlrvsg|/ becoming functional
分享福利
yangzhihong650的博客
03-28 1万+
Redis互联网应用场景总结 https://pan.baidu.com/s/1pmd3UE-p8LGLHYIuweX_0g kp4f 面试必备之并发编程原理分析 面试必备之并发编程原理分析https://pan.baidu.com/s/1wc9Bn_zV26rMhevocfJ4qA 密码：n6kb 分布式任务调度系统的实现 https://pan.baidu.com/...
迅雷下载VS2015地址，快、狠，准
qq_42006303的博客
03-13 6万+
ed2k://|file|cn_visual_studio_community_2015_x86_dvd_6847368.iso|4013920256|EB7F6605EDE67509E218E29173AC6574|/
music1
zhoujie的专栏
03-31 2151
ed2k://|file|%E9%99%B3%E6%BD%94%E9%BA%97%20-%20%E5%BD%A9%E9%9B%B2%E6%AD%B8%E4%BE%86%E6%99%82(CDB).log|4616|0B3BC698C054B2DD89BF463BC25B135C|h=CTE2ZKR7ZT2F23IQZKLIQBVQGP27VGP3|/ ed2k://|file|%E9%99%
php 下载地址提取,PHP提取emule下载ed2k链接
weixin_30491017的博客
03-20 789
有很多类似的链接。现在就是要把这所有的ed2k链接都保存下来，然后批量下载，而不用一个一个点击下载。 实际上就是对应的是：。 现在要做的就是取回相关文件下的除了灰色部分的所有链接对应的页面内容，再从中取出相应的ed2k链接。运行环境如下：OS:Win7 Professional 64bitZend Studio 8.0.1Zend Server Communication Edition: 5....
#0 trendline_update (trend_est=0x1d4bd30, send_delta_ms=<optimized out>, arrival_delta_ms=2671, arriva_ts_ms=18446744073709551615) at webrtc_cc/webrtc_trendline.c:226 #1 0x000e2dcc in delay_bwe_process_feedback_packet (now_ts=<optimized out>, packet=0x1db2668, delay_est=0x1d46228) at webrtc_cc/webrtc_delay_bw_estimator.c:122 #2 delay_bwe_incoming (delay_est=delay_est@entry=0x1d46228, packets=packets@entry=0x1db1d50, packet_num=8421193832936118056, now_ts=now_ts@entry=204117504, acked_bitrate=0, result=result@entry=0x74de177c) at webrtc_cc/webrtc_delay_bw_estimator.c:273 #3 0x000d3bd0 in sender_cc_handle_twcc_packet (sender_cc=0x1d46210, twcc_packets=0x1db1d50, twcc_packets@entry=0x64, packet_num=<optimized out>, now_ts=now_ts@entry=204117504, fraction_lost=fraction_lost@entry=67 'C') at webrtc_cc/webrtc_sender_congestion_controller.c:91 #4 0x000d4718 in sender_bandwidth_estimation_handler (packetType=<optimized out>, customData=<optimized out>, twcc_packets_num=100, twcc_packets=0x1db1d50, duration=7625255, rtt=0, fraction_lost=67 'C') at webrtcserversession.c:480 #5 0x76b23c50 in onRtcpTwccPacket (pRtcpPacket=pRtcpPacket@entry=0x74de18ec, pKvsPeerConnection=0x1db1d50, pKvsPeerConnection@entry=0x1d350d8) at /home/banqilu/code/NVMP/nvmp/build_dir/target-arm-ca9-linux-uclibcgnueabihf-c530wsv2/libkvswebrtcClient/src/source/PeerConnection/Rtcp.c:384 #6 0x76b246b4 in onRtcpPacket (pKvsPeerConnection=pKvsPeerConnection@entry=0x1d350d8, pBuff=pBuff@entry=0x1d55268 "\217", <incomplete sequence \315>, buffLen=28) at /home/banqilu/code/NVMP/nvmp/build_dir/target-arm-ca9-linux-uclibcgnueabihf-c530wsv2/libkvswebrtcClient/src/source/PeerConnection/Rtcp.c:425 #7 0x76b1f360 in onInboundPacket (customData=<optimized out>, buff=buff@entry=0x1d55268 "\217", <incomplete sequence \315>, buffLen=buffLen@entry=30757168) at /home/banqilu/code/NVMP/nvmp/build_dir/target-arm-ca9-linux-uclibcgnueabihf-c530wsv2/libkvswebrtcClient/src/source/PeerConnection/PeerConnection.c:241 #8 0x76b11924 in incomingDataHandler (customData=<optimized out>, pSocketConnection=pSocketConnection@entry=0x1d70ff8, pBuffer=0x1d55268 "\217", <incomplete sequence \315>, bufferLen=42, pSrc=0x74de1a04, pSrc@entry=0x74de1ba0, pDest=0x0, pDest@entry=0x76aef4c0 <globalAtomicLoad>) at /home/banqilu/code/NVMP/nvmp/build_dir/target-arm-ca9-linux-uclibcgnueabihf-c530wsv2/libkvswebrtcClient/src/source/Ice/IceAgent.c:2507 #9 0x76b09518 in connectionListenerReceiveDataRoutine (arg=<optimized out>) at /home/banqilu/code/NVMP/nvmp/build_dir/target-arm-ca9-linux-uclibcgnueabihf-c530wsv2/libkvswebrtcClient/src/source/Ice/ConnectionListener.c:469 #10 0x76a5aa48 in start_thread (arg=0x74de24c0) at libpthread/nptl/pthread_create.c:285 #11 0x769b0c54 in clone () at libc/sysdeps/linux/arm/clone.S:141 上述gdb corddump后结果，packet_num=8421193832936118056没有正确传入，其值应该为100，分析原因
最新发布
10-11
<think>首先，用户提供了一个GDB核心转储的堆栈跟踪，并指出在某个函数中，packet_num的值是8421193832936118056，但它应该被设置为100。用户要求分析原因。 我需要理解堆栈跟踪： - 从#0开始：在函数`trendline_update`中，位于webrtc_cc/webrtc_trendline.c:226。 - #1：在函数`delay_bwe_process_feedback_packet`中，位于webrtc_cc/webrtc_delay_bw_estimator.c:122。 - #2：在函数`delay_bwe_incoming`中，位于同一文件.c:273。 - #3：在函数`sender_cc_handle_twcc_packet`中，位于webrtc_cc/webrtc_sender_congestion_controller.c:91。 - #4：在函数`sender_bandwidth_estimation_handler`中，位于webrtcserversession.c:480。 - #5：在函数`onRtcpTwccPacket`中，位于Rtcp.c:384。 - #6：在函数`onRtcpPacket`中，位于Rtcp.c:425。 - #7：在函数`onInboundPacket`中，位于PeerConnection.c:241。 - #8：在函数`incomingDataHandler`中，位于IceAgent.c:2507。 - #9：在函数`connectionListenerReceiveDataRoutine`中，位于ConnectionListener.c:469。 - #10和#11是线程启动和克隆函数。 关键点是，在堆栈#3中，有： ``` #3 0x000d3bd0 in sender_cc_handle_twcc_packet (sender_cc=0x1d46210, twcc_packets=0x1db1d50, twcc_packets@entry=0x64, packet_num=<optimized out>, now_ts=now_ts@entry=204117504, fraction_lost=fraction_lost@entry=67 'C') at webrtc_cc/webrtc_sender_congestion_controller.c:91 ``` 这里，`packet_num=<optimized out>`，意思是这个值在优化代码中不可用。 在堆栈#4中： ``` #4 0x000d4718 in sender_bandwidth_estimation_handler (packetType=<optimized out>, customData=<optimized out>, twcc_packets_num=100, twcc_packets=0x1db1d50, duration=7625255, rtt=0, fraction_lost=67 'C') at webrtcserversession.c:480 ``` 这里，明确地`twcc_packets_num=100`，这表明在调用`sender_bandwidth_estimation_handler`时，`twcc_packets_num`被设置为100。 用户说`packet_num`应该为100，但在#3中它显示为`<optimized out>`，并且在调试中我们看到它被传入为8421193832936118056，这看起来像一个无效的值。 用户提到在堆栈#2中： ``` #2 delay_bwe_incoming (delay_est=delay_est@entry=0x1d46228, packets=packets@entry=0x1db1d50, packet_num=8421193832936118056, now_ts=now_ts@entry=204117504, acked_bitrate=0, result=result@entry=0x74de177c) at webrtc_cc/webrtc_delay_bw_estimator.c:273 ``` 所以，在`delay_bwe_incoming`中，`packet_num`被传入为8421193832936118056。 现在，分析原因： - 这个值8421193832936118056非常大，接近2^63（9223372036854775808），这看起来像一个未初始化的指针或错误的值。 - 在堆栈中，从#4到#3的调用：`sender_bandwidth_estimation_handler`调用`sender_cc_handle_twcc_packet`。 - 在#4，我们有`twcc_packets_num=100`，这应该是正确的值。 - 但在#3，当调用`sender_cc_handle_twcc_packet`时，参数`packet_num`是`<optimized out>`，意思是编译器优化掉了这个参数，或者值在调试时不可用。 - 实际在#2，我们看到`packet_num=8421193832936118056`，这可能意味着在函数调用链中，这个值被错误地传递或修改。 查看调用路径： - #4: `sender_bandwidth_estimation_handler` calls `sender_cc_handle_twcc_packet` (likely) - #3: `sender_cc_handle_twcc_packet` then calls `delay_bwe_incoming` (as seen in stack #2) 在堆栈中，#3是`sender_cc_handle_twcc_packet`，然后#2是`delay_bwe_incoming`。 在#4中，`twcc_packets_num=100`被传入到`sender_bandwidth_estimation_handler`（但函数签名中参数是`twcc_packets_num`，应该是packet number）。 在#3中，`sender_cc_handle_twcc_packet`有参数`packet_num`，但它被优化掉了。 问题可能出在参数传递中。 可能的原因： 1. **函数签名不匹配**：在调用`sender_cc_handle_twcc_packet`时，传入的参数类型错误或顺序错误。 2. **内存损坏**：栈或堆损坏导致值被覆盖。 3. **优化问题**：由于编译器优化，调试信息不完整，但实际值被错误计算。 4. **无效指针或数组访问**：在之前的代码中，访问无效内存导致错误的值被传递。 具体看堆栈#4： - `sender_bandwidth_estimation_handler` 在 webrtcserversession.c:480 - 它调用`sender_cc_handle_twcc_packet`？看堆栈，#3 is called after #4, so likely #4 calls functions that lead to #3. 从堆栈顺序，#4 is at webrtcserversession.c:480, then #3 is at webrtc_sender_congestion_controller.c:91, so probably `sender_bandwidth_estimation_handler` calls `sender_cc_handle_twcc_packet`. 在#4，参数是`twcc_packets_num=100`，所以当调用`sender_cc_handle_twcc_packet`时，它应该传入这个值作为`packet_num`。 但在#3，`packet_num` is optimized out, meaning in the compiled code, it might not be preserved. 在#2，当`delay_bwe_incoming`被调用时，`packet_num`是8421193832936118056。 看函数原型或代码： - In #2, `delay_bwe_incoming` has parameters including `packet_num`. - In #3, `sender_cc_handle_twcc_packet` likely calls `delay_bwe_incoming`. 因此，问题可能出在`sender_cc_handle_twcc_packet`中，当它调用`delay_bwe_incoming`时，传入的`packet_num`参数是错误的。 为什么错误？ - 可能`sender_cc_handle_twcc_packet`没有正确处理传入的`packet_num`。 - 或者，在优化代码中，值被错误地计算。 8421193832936118056 in hex is approximately 0x7500000000000000, which might be an address or garbage value. 考虑到在#3中，`twcc_packets@entry=0x64`, which is 100 in decimal. 0x64 is 100. So `twcc_packets@entry=0x64` might be a typo or misinterpretation in debug output. 查看#3： ``` twcc_packets=0x1db1d50, twcc_packets@entry=0x64 ``` `twcc_packets@entry=0x64` – 0x64 is 100 in decimal, so this might be the number of packets, not the packet number. But in the parameter list, it's shown as `twcc_packets@entry=0x64`, which is odd because `twcc_packets` is likely a pointer to packets. 或许`twcc_packets@entry`表示传入的值，`twcc_packets`是当前值。但0x64是100，可能`twcc_packets_num`被错误地传递为指针。 在函数签名中： ``` sender_cc_handle_twcc_packet (sender_cc=0x1d46210, twcc_packets=0x1db1d50, twcc_packets@entry=0x64, packet_num=<optimized out>, ...) ``` 我认为`twcc_packets@entry=0x64` is a debug annotation showing the entry value of `twcc_packets` parameter was 0x64, which is 100, but `twcc_packets` itself is a pointer (0x1db1d50), so it doesn't make sense. 这很混乱。可能调试输出有误，或者代码中有错误。 另一个想法：在#4中，调用参数是`twcc_packets_num=100`，但当调用`sender_cc_handle_twcc_packet`时，参数顺序可能错了。 假设在C代码中，函数定义： void sender_cc_handle_twcc_packet(sender_cc_t* sender_cc, uint32_t packet_num, ...) 但调用时，可能传入了错误的值。 或者，在堆栈#2中，`packet_num`来自其他地方。 在#2，`delay_bwe_incoming`被调用时`packet_num=8421193832936118056`，但应该来自`packets`结构或其他东西。 用户说"packet_num=8421193832936118056没有正确传入，其值应该为100"，意思是它应该为100。 在调用链中，从#4的100到#2的错误值，问题发生在#3的函数中。 可能的原因： - 在`sender_cc_handle_twcc_packet`中，当调用`delay_bwe_incoming`时，它传入了一个错误的`packet_num`值。 - 例如，它可能错误地使用了`twcc_packets`指针的值，而不是`packet_num`。 - 在#3中，`twcc_packets`是0x1db1d50，而`packet_num`被优化掉，但可能代码中使用了`twcc_packets`作为数字或其他错误。 或者，在`delay_bwe_incoming`中，`packet_num`参数被误解。 另一个线索：在#1和#0中，我们看到`trendline_update`被调用，但`delay_bwe_process_feedback_packet`在#1中调用它。 但焦点在`packet_num`上。 基于堆栈，分析错误： - 在 `sender_bandwidth_estimation_handler` (webrtcserversession.c:480)，`twcc_packets_num` 是 100。 - 它调用 `sender_cc_handle_twcc_packet`，其中 `packet_num` 应该被设置为 100。 - 但在 `sender_cc_handle_twcc_packet` 内部（webrtc_sender_congestion_controller.c:91），这个值没有被正确传递，或者当它调用 `delay_bwe_incoming` 时，它传入了错误的值。 - 在 `delay_bwe_incoming` 中，`packet_num` 是 8421193832936118056，这可能是一个未初始化的值或内存错误。 常见原因： - **参数顺序错误**：在函数调用中，参数顺序与函数声明不匹配。 - **类型不匹配**：`packet_num` 可能应该是 `uint32_t` 或类似类型，但传入了指针。 - **内存覆盖**：栈或堆损坏导致参数被覆盖。 - **优化错误**：编译器优化引入错误，但可能性较小。 - **并发问题**：如果有多个线程，可能导致数据竞争。 但在这个堆栈中，它似乎是在一个线程中（从#10开始是pthread）。 建议检查源代码： - 在 `webrtcserversession.c` 中，查找 `sender_bandwidth_estimation_handler` 函数，看看它是如何调用 `sender_cc_handle_twcc_packet` 的。参数顺序是否正确？ - 在 `webrtc_sender_congestion_controller.c` 中，检查 `sender_cc_handle_twcc_packet` 函数，看看它如何使用 `packet_num` 以及如何调用 `delay_bwe_incoming`。 在缺乏源代码的情况下，大致推断： - 值 8421193832936118056 可能是一个指针值（例如，0x7500000000000000），被错误地解释为一个数字。 - 在 #3 中，`twcc_packets=0x1db1d50`，而 `twcc_packets@entry=0x64`（100），但 `twcc_packets` 应该是一个指向数据包的指针，所以 0x1db1d50 是地址，0x64 可能表示传入的数量之类的信息。 `twcc_packets@entry=0x64` 可能表示在函数入口时，`twcc_packets` 的值是 0x64，但之后被修改了之类的。但在堆栈中，它显示为参数。 这很令人困惑。我应该专注于为什么 `packet_num` 在 #2 中是错的。 在回答中，我需要用中文写，并最后提出3-5个相关问题。 回答结构： 1. 分析可能原因。 2. 建议解决方案。 3. 以“§§相关问题§§”开头列出相关问题。 最终答案： - 可能原因是函数参数传递错误或内存损坏。 - 检查函数调用和参数类型。 提出相关问题： 1. 在发送方带宽估计处理程序中，twcc_packets_num是如何传递给sender_cc_handle_twcc_packet的？ 2. 在sender_cc_handle_twcc_packet函数中，packet_num参数是如何处理的？ 3. delay_bwe_incoming函数期望的packet_num参数类型是什么？ 4. 是否可能存在内存损坏或优化问题导致数值错误？ 5. 如何重现这个错误以进行调试？ 确保3-5个问题。 </think>### 分析原因 根据提供的GDB核心转储堆栈，`packet_num`在函数`delay_bwe_incoming`中被错误传入为8421193832936118056（十六进制约为0x7500000000000000），而预期值应为100。该值出现在堆栈帧#2中，但错误可能起源于更早的调用链。以下是主要原因分析： 1. **函数参数传递错误**： - 在堆栈帧#4（`sender_bandwidth_estimation_handler`），`twcc_packets_num=100`被正确设置，表明上层传入的值是100。 - 在堆栈帧#3（`sender_cc_handle_twcc_packet`），参数`packet_num`被标记为`<optimized out>`，表示编译器优化可能隐藏了实际值，但当调用`delay_bwe_incoming`（帧#2）时，`packet_num`被传入一个无效值（8421193832936118056）。 - 可能原因：调用`delay_bwe_incoming`时，参数顺序或类型不匹配。例如： - `sender_cc_handle_twcc_packet`可能错误地将一个指针值（如`packets`地址）当作`packet_num`传入。 - 函数原型声明不一致（如`packet_num`应为`uint32_t`，但传入时被错误解释为指针或更大类型）。 2. **内存损坏或未初始化值**： - 值8421193832936118056接近64位系统的最大地址值（0x7FFFFFFFFFFFFFFF），这表明它可能是一个未初始化的指针或栈/堆内存损坏的结果。 - 堆栈中`twcc_packets=0x1db1d50`和`twcc_packets@entry=0x64`（0x64=100）的冲突显示，参数可能在函数内部被覆盖（如并发访问或缓冲区溢出）。 - 常见场景：在`delay_bwe_process_feedback_packet`（帧#1）或相关函数中，数组访问越界或无效指针解引用，导致`packet_num`被错误赋值。 3. **编译器优化问题**： - 标记为`<optimized out>`表示代码优化（如GCC的`-O2`）可能内联函数或省略参数保存，致值在调试时不可见。但优化本身较少直接导致值错误，除非代码逻辑缺陷（如依赖未定义行为）。 - 实际值错误更可能源于源代码错误，而非优化本身。 4. **潜在代码缺陷**： - 在调用链中（`sender_bandwidth_estimation_handler` → `sender_cc_handle_twcc_packet` → `delay_bwe_incoming`），检查`webrtc_sender_congestion_controller.c`和`webrtc_delay_bw_estimator.c`的源代码： - 确认`delay_bwe_incoming`的调用参数是否与声明匹配。 - 验证`packet_num`是否被意外替换为其他变量（如`packets`指针值）。 - 例如，在`webrtc_sender_congestion_controller.c:91`，代码可能类似： ```c delay_bwe_incoming(sender_cc->delay_est, twcc_packets, packet_num, ...); // 如果packet_num未正确设置，则传入垃圾值 ``` **建议调试步骤**： - 关闭编译器优化（如GCC的`-O0`），重新编译并运行，以捕获完整参数值。 - 使用Valgrind或AddressSanitizer检查内存错误（如越界访问）。 - 审查相关函数的源代码，确保参数类型和顺序一致： - `sender_cc_handle_twcc_packet`的`packet_num`应直接来自`twcc_packets_num`。 - 在`delay_bwe_incoming`中，添加日志以打印`packet_num`值。 - 检查并发问题：堆栈显示线程上下文（帧#10），多线程中数据竞争可能导致值被覆盖。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值