记一次go panic问题的解决过程

最新推荐文章于 2024-07-22 23:03:47 发布
最新推荐文章于 2024-07-22 23:03:47 发布
阅读量3.5k 收藏
点赞数
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/bigwhite20xx/article/details/93817008
版权
640



一. Panic问题概述


本周收到客户在bugclose上填写的一个issue：添加一个下发通道后，pushd程序panic并退出了！程序panic时输出的stacktrace信息摘录如下：


 
 
panic: runtime error: invalid memory address or nil pointer dereference[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x8ca449]goroutine 266900 [running]:pkg.tonybai.com/smspush/vendor/github.com/bigwhite/gocmpp.(*Client).Connect(0xc42040c7f0, 0xc4203d29c0, 0x11, 0xc420423256, 0x6, 0xc420423260, 0x8, 0x37e11d600, 0x0, 0x0)        /root/.go/src/pkg.tonybai.com/smspush/vendor/github.com/bigwhite/gocmpp/client.go:79 +0x239pkg.tonybai.com/smspush/pkg/pushd/pusher.cmpp2Login(0xc4203d29c0, 0x11, 0xc420423256, 0x6, 0xc420423260, 0x8, 0x37e11d600, 0xc4203d29c0, 0x11, 0x73)        /root/.go/src/pkg.tonybai.com/smspush/pkg/pushd/pusher/cmpp2_handler.go:25 +0x9apkg.tonybai.com/smspush/pkg/pushd/pusher.newCMPP2Loop(0xc42071f800, 0x4, 0xaaecd8)        /root/.go/src/pkg.tonybai.com/smspush/pkg/pushd/pusher/cmpp2_handler.go:65 +0x226pkg.tonybai.com/smspush/pkg/pushd/pusher.(*tchanSession).Run(0xc42071f800, 0xaba7c3, 0x17)        /root/.go/src/pkg.tonybai.com/smspush/pkg/pushd/pusher/session.go:52 +0x98pkg.tonybai.com/smspush/pkg/pushd/pusher.(*gateway).addSession.func1(0xc4200881a0, 0xc42071f800, 0xc42040c700)        /root/.go/src/pkg.tonybai.com/smspush/pkg/pushd/pusher/gateway.go:61 +0x11ecreated by pkg.tonybai.com/smspush/pkg/pushd/pusher.(*gateway).addSession        /root/.go/src/pkg.tonybai.com/smspush/pkg/pushd/pusher/gateway.go:58 +0x350or nil pointer dereference

[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x8ca449]



goroutine 266900 [running]:

pkg.tonybai.com/smspush/vendor/github.com/bigwhite/gocmpp.(*Client).Connect(0xc42040c7f0, 0xc4203d29c0, 0x11, 0xc420423256, 0x6, 0xc420423260, 0x8, 0x37e11d600, 0x0, 0x0)

        /root/.go/src/pkg.tonybai.com/smspush/vendor/github.com/bigwhite/gocmpp/client.go:79 +0x239

pkg.tonybai.com/smspush/pkg/pushd/pusher.cmpp2Login(0xc4203d29c0, 0x11, 0xc420423256, 0x6, 0xc420423260, 0x8, 0x37e11d600, 0xc4203d29c0, 0x11, 0x73)

        /root/.go/src/pkg.tonybai.com/smspush/pkg/pushd/pusher/cmpp2_handler.go:25 +0x9a

pkg.tonybai.com/smspush/pkg/pushd/pusher.newCMPP2Loop(0xc42071f800, 0x4, 0xaaecd8)

        /root/.go/src/pkg.tonybai.com/smspush/pkg/pushd/pusher/cmpp2_handler.go:65 +0x226

pkg.tonybai.com/smspush/pkg/pushd/pusher.(*tchanSession).Run(0xc42071f800, 0xaba7c3, 0x17)

        /root/.go/src/pkg.tonybai.com/smspush/pkg/pushd/pusher/session.go:52 +0x98

pkg.tonybai.com/smspush/pkg/pushd/pusher.(*gateway).addSession.func1(0xc4200881a0, 0xc42071f800, 0xc42040c700)

        /root/.go/src/pkg.tonybai.com/smspush/pkg/pushd/pusher/gateway.go:61 +0x11e

created by pkg.tonybai.com/smspush/pkg/pushd/pusher.(*gateway).addSession

        /root/.go/src/pkg.tonybai.com/smspush/pkg/pushd/pusher/gateway.go:58 +0x350
 
 

 
 
印象中近大半年用Go写的程序，遇到panic情况不多。上一次是因为原生map变量的并发访问导致的panic，那次panic一眼就看到问题所在了。但这次又是因为啥呢？
 
 

 
 

 
 

 
 
二. 分析和debug过程 
 
 

 
 
这个问题在印象中似乎出现过，不过由于当初没有复现，客户环境中又没有panic信息提供，那时没能定位和解决，后来问题并没有出现，显然这个问题是有一定“随机属性”。
 
 

 
 
对于panic，我们首先检查直接导致panic发生的那一行代码：
 
 

 
 
        /root/.go/src/pkg.tonybai.com/smspush/vendor/github.com/bigwhite/gocmpp/client.go:79 +0x239
 
 

 
 
下面是client.go 79行周围的代码片段：
 
 

 
 
640?wx_fmt=png
 
 

 
 
也许是疏忽大意，当时瞅了一眼后，就断定这块没有问题（更多从业务协议层面考虑），这也直接导致后面绕了一个大圈子才查到”真凶”。如果您还没看出来问题，那继续往下看。
 
 

 
 
定式思维让我认为很可能是函数栈中的内存问题，于是我开始调查panic输出的函数调用栈中参数是否正确。
 
 

 
 
要想知道函数调用栈中参数传递是否有问题，先要知晓panic后输出的栈帧信息都是什么！比如下面panic dump信息中参数中的各种magic number都代表什么！
 
 

 
 
 
 
gocmpp.(*Client).Connect(0xc42040c7f0, 0xc4203d29c0, 0x11, 0xc420423256, 0x6, 0xc420423260, 0x8, 0x37e11d600, 0x0, 0x0)pusher.cmpp2Login(0xc4203d29c0, 0x11, 0xc420423256, 0x6, 0xc420423260, 0x8, 0x37e11d600, 0xc4203d29c0, 0x11, 0x73)pusher.newCMPP2Loop(0xc42071f800, 0x4, 0xaaecd8)0xc4203d29c0, 0x11, 0xc420423256, 0x6, 0xc420423260, 0x8, 0x37e11d600, 0x0, 0x0)



pusher.cmpp2Login(0xc4203d29c0, 0x11, 0xc420423256, 0x6, 0xc420423260, 0x8, 0x37e11d600, 0xc4203d29c0, 0x11, 0x73)



pusher.newCMPP2Loop(0xc42071f800, 0x4, 0xaaecd8)
 
 

 
 
在Joe Shaw的《Understanding Go panic output》和William Kennedy的《Stack Traces In Go》中有针对Stack trace输出信息的解析。关于Stack trace输出信息的识别，总体遵循几个要点：
 
 

 
 
  • stack trace中每个函数/方法后面的“参数数值”个数与函数/方法原型的参数个数不是一一对应的；

  • stack trace中每个函数/方法后面的“参数数值”是按照函数/方法原型参数列表中从左到右的参数类型的内存布局逐一展开的; 每个数值占用一个word(64位平台下面为8字节)

  • 如果是method，则第一个参数是receiver自身。如果reciever是指针类型，则第一个参数数值就是一个指针地址；如果是非指针的实例，则stack trace会按照其内存布局输出；

  • 函数/方法返回值放在stack trace的“参数数值”列表的后面；如果有多个返回值，则同样按从左到右顺序，按照返回值类型的内存布局输出；

  • 指针类型参数：占用stack trace的“参数数值”列表的1个位置；数值表示指针值，也是指针指向的对象的地址；

  • string类型参数：由于string在内存中由两个字(word)表示，第一个字是数据指针，第二个字是string的长度，因此在stack trace的“参数数值”列表中将占用两个位置；

  • slice类型参数：由于slice类型在内存中由三个字表示，第一个word是数据指针，第二个word是len，第三个字是cap，因此在stack trace的“参数数值”列表中将占用三个位置；

  • 内建整型(int,rune,byte)：由于按word逐个输出，对于类型长度不足一个Word的参数，会做合并处理；比如：一个函数有5个int16类型的参数，那么在stack trace的信息中，这5个参数将占用stack trace的“参数数值”列表中的两个位置；第一个位置是前4个参数的“合体”，第二个位置则是最后那个int16类型的参数值。

  • struct类型参数: 会按照struct中字段的内存布局顺序在stack trace中展开。

  • interface类型参数：由于interface类型在内存中由两部分组成，一部分是接口类型的参数指针，一部分是接口值的参数指针，因此interface类型参数将用stack trace的“参数数值”列表中的两个位置。

  • stack trace输出的信息是在函数调用过程中的“快照”信息，因此一些输出数值看似不合理，但是由于其并不是最终值，所以问题不一定发生在这些参数身上，比如：返回值参数。
 
 

 
 
结合上面要点、函数/方法原型以及stack trace的输出，我们来“定位”一下stack trace输出的各个“参数”的含义：
 
 

 
 
cmpp2Login和Connect的原型以及调用关系如下：
 
 

 
 
 
 
func cmpp2Login(dstAddr, user, password string, connectTimeout time.Duration) (*cmpp.Client, error)func (cli *Client) Connect(servAddr, user, password string, timeout time.Duration) errorfunc cmpp2Login(dstAddr, user, password string, connectTimeout time.Duration) (*cmpp.Client, error) {    c := cmpp.NewClient(cmpp.V21)    return c, c.Connect(dstAddr, user, password, connectTimeout)}cmpp2Login(dstAddr, user, password string, connectTimeout time.Duration) (*cmpp.Client, error)



func (cli *Client) Connect(servAddr, user, password string, timeout time.Duration) error



func cmpp2Login(dstAddr, user, password string, connectTimeout time.Duration) (*cmpp.Client, error) {

c := cmpp.NewClient(cmpp.V21)

    return c, c.Connect(dstAddr, user, password, connectTimeout)

}
 
 

 
 
对照后，我们得出下面对应关系：
 
 

 
 
 
 
pusher.cmpp2Login(        0xc4203d29c0,  // dstAddr的data pointer        0x11,                  // dstAddr string的length        0xc420423256,  // user 的data pointer        0x6,                    // user string的length        0xc420423260,  // password的data pointer        0x8,                    // password string的length        0x37e11d600,    // connectTimeout        0xc4203d29c0,  // 返回值：Client的指针        0x11,                 // 返回值：error接口的type pointer        0x73)                 // 返回值：error接口的data pointergocmpp.(*Client).Connect(        0xc42040c7f0,   //cli的指针        0xc4203d29c0,  //servAddr string的data pointer        0x11,                  //servAddr string的 length        0xc420423256,  // user string的data pointer        0x6,                    // user string的length        0xc420423260,  // password的data pointer        0x8,                    // password string的length        0x37e11d600,   // timeout        0x0,                   // 返回值：error接口的type pointer        0x0)                   // 返回值：error接口的data pointer
0xc4203d29c0,  // dstAddr的data pointer

0x11,                  // dstAddr string的length

0xc420423256,  // user 的data pointer

0x6,                    // user string的length

0xc420423260,  // password的data pointer

0x8,                    // password string的length

0x37e11d600,    // connectTimeout

0xc4203d29c0,  // 返回值：Client的指针

0x11,                 // 返回值：error接口的type pointer

0x73)                 // 返回值：error接口的data pointer



gocmpp.(*Client).Connect(

0xc42040c7f0,   //cli的指针

0xc4203d29c0,  //servAddr string的data pointer

0x11,                  //servAddr string的 length

0xc420423256,  // user string的data pointer

0x6,                    // user string的length

0xc420423260,  // password的data pointer

0x8,                    // password string的length

0x37e11d600,   // timeout

0x0,                   // 返回值：error接口的type pointer

0x0)                   // 返回值：error接口的data pointer
 
 

 
 
在这里，cmpp2Login的dstAddr、user、password、connectTimeout这些输入参数值都非常正常；看起来不正常的两个返回值在栈帧中的值其实意义不大，因为connect没有返回，所以这些值处于“非最终态”；而Connect执行到第79行panic，因此其返回值error的两个值也是处于“中间状态”。
 
 

 
 
这样一来，似乎没有参数是错误的！
 
 

 
 

 
 

 
 
三. 回到起点，捉住“真凶” 
 
 

 
 
在反复查看代码和对比stack trace的参数列表后，依然没有找到蛛丝马迹。遂决定平复心情，从头再来，回到起点！
 
 

 
 
        
 
 
 
 
var ok bool        var status uint8        if cli.typ == V20 || cli.typ == V21 {                var rsp *Cmpp2ConnRspPkt                rsp, ok = p.(*Cmpp2ConnRspPkt)                status = rsp.Status        } else {                var rsp *Cmpp3ConnRspPkt                rsp, ok = p.(*Cmpp3ConnRspPkt)                status = uint8(rsp.Status)   <------ 79行        }        if !ok {                err = ErrRespNotMatch                return err        }bool

var status uint8

if cli.typ == V20 || cli.typ == V21 {

var rsp *Cmpp2ConnRspPkt

                rsp, ok = p.(*Cmpp2ConnRspPkt)

                status = rsp.Status

        } else {

var rsp *Cmpp3ConnRspPkt

                rsp, ok = p.(*Cmpp3ConnRspPkt)

                status = uint8(rsp.Status)   <------ 79行

        }



if !ok {

                err = ErrRespNotMatch

return err

        }
 
 

 
 
又反复看了这段代码！程序正常执行时都是经过这段代码的，都是正常的。为何随机爆出panic呢？79行如果要panic，显然是rsp为nil或其他非法地址。但rsp是由p进行type assertion而来的！难道是type assertion失败了！！！
 
 

 
 
从正常业务流程来看，这里是不会失败的！这也是当初这里没有立即检查ok这个bool值的原因。但是特殊情况下，也就是当tcp连接建立后，conn包发出后，对方未必返回是conn response包，很可能是其他包回来（比如active test），这样就会导致这块的type assertion失败！这也与这个问题随机发生的情况吻合！
 
 

 
 
而且当初保留了“ok”，而不是用”_”代替，说明设计思路中是存在返回的包不是conn response包的情况。看来是当初coding时逻辑混乱了:(
 
 

 
 
这就是问题所在了！教训：type assertion后一定要在检查ok这个bool值之后再决定是否使用assertion之后的变量。
 
 

 
 

 
 

 
 
 四. 其他
 
 

 
 
借着这个问题的解决过程，再多说一句 stacktrace。在Go 1.11及以后版本中，go compiler做了更深入的优化，很多“简单”的函数或方法会被自动inline(内联)了，函数一旦内联化了，那么在stack trace中我们就无法看到栈帧信息了，就会看到如下在栈帧信息中存在省略号的情况：
 
 

 
 
 
 
 
 
 
$go run stacktrace.gopanic: panic in foogoroutine 1 [running]:main.(*Y).foo(...)    /Users/tony/test/go/stacktrace/stacktrace2.go:32main.main()    /Users/tony/test/go/stacktrace/stacktrace.go:51 +0x39exit status 2go

panic: panic in foo



goroutine 1 [running]:

main.(*Y).foo(...)

    /Users/tony/test/go/stacktrace/stacktrace2.go:32

main.main()

    /Users/tony/test/go/stacktrace/stacktrace.go:51 +0x39

exit status 2
 
 
可以使用-gcflags=”-l”来告诉编译器不要inline。至于是否要这么做，就要看debug和性能之间您是如何权衡的了。
 
 

 
 
 
 
我的网课“Kubernetes实战：高可用集群搭建、配置、运维与应用”在慕课网上线了，感谢小伙伴们学习支持！https://coding.imooc.com/class/284.html
 
 

 
 
我爱发短信：企业级短信平台定制开发专家 https://51smspush.com/
 
 
smspush : 可部署在企业内部的定制化短信平台，三网覆盖，不惧大并发接入，可定制扩展； 短信内容你来定，不再受约束, 接口丰富，支持长短信，签名可选。
 
 

 
 
著名云主机服务厂商DigitalOcean发布最新的主机计划，入门级Droplet配置升级为：1 core CPU、1G内存、25G高速SSD，价格5$/月。有使用DigitalOcean需求的朋友，可以打开这个链接地址：https://m.do.co/c/bff6eed92687 开启你的DO主机之路。
 
 

 
 
我的联系方式：
 
 

 
 
微博：https://weibo.com/bigwhite20xx
 
 
微信公众号：iamtonybai
 
 
博客：tonybai.com
 
 
github: https://github.com/bigwhite
 
 

 
 
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。
 
 

 
 
© 2019, bigwhite. 版权所有.
 
 640 
 

 
 
点击阅读原文查看更多
 
 

 


                

        

        

    

  


    

      

        

            

              
                
                  Tony Bai
                
              
            

            

                关注
              
            

        

        

          
      

      









                



	

		

			

				
					
Golang捕获panic堆栈信息的讲解

				
			

			

				

					09-19
				

			

		

		

			
				
在Golang编程中，`panic` 是一种异常处理机制，用于表示程序遇到了无法正常处理的错误情况。通常，当`panic`被触发时，程序会立即停止执行，并打印出堆栈跟踪信息。然而，这种默认行为在多goroutine环境下可能会导致...

			
		

	



                

              
                



	

		

			

				
					
Golang sync.WaitGroup 简介与用法

				
			

			

				

					Dablelv 的博客专栏。
				

				

					07-12
					
					4472
					
				

			

		

		

			
				
1.简介
sync.WaitGroup 用于阻塞等待一组 Go 程的结束。主 Go 程调用 Add() 来设置等待的 Go 程数，然后该组中的每个 Go 程都会运行，并在结束时调用 Done()， 递减 WaitGroup 的 counter。
type WaitGroup struct {
    // contains filtered or unexported fields
}

//设置..................

			
		

	



                


  
              

                


	

		

			

				
					
简单介绍Go sync WaitGroup使用深入理解

				
			

			

				

					Free雅轩的博客
				

				

					11-17
					
					560
					
				

			

		

		

			
				
只要 WaitGroup 的计值恢复到零值的状态，那么它就可以被看作是新创建的 WaitGroup，被重复使用，而不能在前一组没使用完的情况下又使用。而用WaitGroup时，协程A只用阻塞，直到其他协程执行完毕后，再通知协程A,其他语言也提供了类似的工具，例如Java的CountDownLatch。因此使用 WaitGroup 的正确姿势是，预先确定好 WaitGroup 的计数值，然后调用相同次数的 Done 完成相应的任务。// 如果加完后v大于0，或者加完后v等于0，但没有等待者，直接返回。

			
		

	





	

		

			

				
					
`panic` 是 Go 语言中用来表示发生了严重错误的一种机制

					
最新发布

				
			

			

				

					喝醉酒的小白
				

				

					07-22
					
					1383
					
				

			

		

		

			
				
在 Go 程序中， 是一种运行时错误，它会导致当前的 goroutine 立即停止执行，并开始进行栈展开（unwinding the stack）。简单来说， 是 Go 语言中用来表示发生了严重错误的一种机制。以下是一些关于 Go 程序中  的要点：触发原因：栈展开：程序终止：错误处理：Defer 函数：Recover：日志记录：调试：性能影响：并发中的 panic：在编写 Go 程序时，应该谨慎使用 panic，因为它是一种异常机制，不适用于常规的错误处理。正确使用 panic 可以帮助你处理那些不应该发

			
		

	



		

			
		



	

		

			

				
					
go-waitgroup介绍

				
			

			

				

					u013092227的博客
				

				

					06-25
					
					325
					
				

			

		

		

			
				
一、waitgroup介绍
多线程编程中，经常会遇到这样的一种场景：main函数中为了等待其他线程执行完，在return之前都要执行sleep以争取更多的时间给其他线程执行。例如：
package main

import (
    "fmt"
    "time"
)

func main(){
    for i := 0; i < 100 ; i++{
        go fmt.Println(i)
    }
    time.Sleep(time.Second)
}

主线程为了等待g

			
		

	





	

		

			

				
					
记使用WaitGroup时的一个错误

				
			

			

				

					拙言的专栏
				

				

					06-12
					
					1万+
					
				

			

		

		

			
				
记使用WaitGroup时的一个错误最近重构服务器代码时，不当使用了WaitGroup,碰到了个错误,记录下.package mainimport (
    "fmt"
    "sync"
    "time"
)func main() {
    var wg sync.WaitGroup
    wg.Add(1)    f1 := func() {
        time.Sleep(t

			
		

	





	

		

			

				
					
谈谈Golang的同步等待组

				
			

			

				

					weixin_44433834的博客
				

				

					12-30
					
					632
					
				

			

		

		

			
				
作者：ReganYue
来源：恒生LIGHT云社区

大家好，这里是努力变得优秀的R君，这次我们继续来进行Golang系列《让我们一起Golang》，区块链系列内容明年会继续更新，共识算法已经基本完毕，如果不出意外，元旦那个星期就是介绍如何构建公链项目了，本次我们来了解Golang的同步等待组，这也是一个比较容易理解的知识点，我们来看一看吧！
我们现在开十条子协程，然后当十条子协程全部结束后，主协程立马结束。动动你的小脑袋，想一想应该怎么做？如果是一条子协程的话就很容易实现，当这条子协程结束时让主协程结束.

			
		

	





	

		

			

				
					
go语言的panic和recover函数用法实例

				
			

			

				

					09-19
				

			

		

		

			
				
第一次尝试成功捕获了恐慌，并输出了`panic`的值。第二次尝试没有捕获到恐慌，因此输出了`haha`。  #### 五、注意事项 1. **不要滥用panic-recover**：虽然`panic-recover`机制提供了强大的错误处理能力，但不应过度...

			
		

	





	

		

			

				
					
go语言异常panic和恢复recover用法实例

				
			

			

				

					09-22
				

			

		

		

			
				
在Go语言中，异常处理机制不同于其他编程语言，如Java或Python。Go使用`panic`和`recover`这两个内建函数来实现异常处理。本文将详细介绍`panic`和`recover`的用法，并通过实例来解析它们的使用技巧。  1. `panic` ...

			
		

	





	

		

			

				
					
GO语言异常处理机制panic和recover分析

				
			

			

				

					01-21
				

			

		

		

			
				
本文实例分析了GO语言异常处理机制panic和recover。分享给大家供大家参考。具体如下： Golang 有2个内置的函数 panic() 和 recover()，用以报告和捕获运行时发生的程序错误，与 error 不同，panic-recover 一般用在...

			
		

	





	

		

			

				
					
panic: runtime error: invalid memory address or nil pointer dereference

					
热门推荐

				
			

			

				

					mei2532的专栏
				

				

					03-13
					
					2万+
					
				

			

		

		

			
				
报错：

panic: runtime error: invalid memory address or nil pointer dereference

[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x488c7d]

goroutine 29 [running]:

panic(0xa0cb60, 0xc420016...

			
		

	





	

		

			

				
					
由浅入深聊聊Golang中select的实现机制

				
			

			

				

					咖啡色的羊驼
				

				

					08-31
					
					1万+
					
				

			

		

		

			
				
正文

话说今天在玩select的时候发现一个问题，是这样的：

片段1：

func main(){
    var count int
    for {
        select {
        case &amp;amp;amp;amp;lt;-time.Tick(time.Millisecond * 500):
            fmt.Println(&amp;amp;amp;quot;咖啡色的羊驼&amp;amp;amp;quot;)
          

			
		

	





	

		

			

				
					
supervisor配置gogs记录

				
			

			

				

					String12的博客
				

				

					11-09
					
					1233
					
				

			

		

		

			
				
问题一：不能使用 gosu 调用 git 用户来启动
发现不能使用 gosu 调用 git 用户来启动，gosu git /home/git/gogs/gogs web 会报如下错误：
gogs 运行系统用户非当前用户：git &gt;
不推荐的解决方法是： 切换到git账户下执行：su - git $ ./gogs web
通过测试，可以采用如下的方式来使用 gosu 调用 git 用户（参考自...

			
		

	





	

		

			

				
					
Go - 捕获 panic 信息到日志文件中

				
			

			

				

					weixin_33717117的博客
				

				

					11-28
					
					3041
					
				

			

		

		

			
				
2019独角兽企业重金招聘Python工程师标准>>>   
                                        
         ...

			
		

	





	

		

			

				
					
Go 编程问题 package runtime/pprof is not in GOROOT

				
			

			

				

					阿哥的专栏
				

				

					12-03
					
					1563
					
				

			

		

		

			
				
../../../go/pkg/mod/github.com/micro/go-micro@v1.16.0/server/rpc_server.go:8:2: package runtime/debug is not in GOROOT (/usr/local/opt/go@1.14/src/runtime/debug)
../../../go/pkg/mod/github.com/micro/go-micro@v1.16.0/debug/profile/pprof/pprof.go:8:2: packa.

			
		

	





	

		

			

				
					
Golang 中比较常见的 panic 异常原因之一

				
			

			

				

					liuzhen007的专栏
				

				

					11-27
					
					5564
					
				

			

		

		

			
				
目录

前言

正文

结尾

前言

在 Golang 中，当异常发生时不管是主动触发 panic 还是由于编码错误导致的 panic，我们都可以使用 recover 进行捕获。当时前提必须定义 defer 语句，且 defer 必须放在 panic 之前定义，另外 recover 只有在 defer 调用的函数中才有效。

正文

今天本文介绍一个编码不规范导致的 panic 异常，下面是错误日志，从日志中我们可以看到程序发生了 panic 异常，并且这个 panic 已经 Gin 框架自带的 Reco

			
		

	





	

		

			

				
					
记一次go-panic引发的消息堆积

				
			

			

				

					qq_39679639的博客
				

				

					05-22
					
					791
					
				

			

		

		

			
				
背景
业务上使用生产-消费模式处理第三方上报的异步消息；job服务作为消费者，以常驻线程的方式，统一消费各个topic的消息（业务使用kafka做消息队列），然后通过同步调用业务接口使消息生效，数据流大致如下：

一条异常消息引发的惨案
一天中午，在uat环境出现队列消息堆积、数据无写入的现象，快速定位到job-service服务容器一直处于重启中，无法正常工作；通过重启日志，发现一个topic的消费者在消费某条消息时panic，导致整个job服务宕机，虽然discovery服务检测到心跳异常后不断重启，但

			
		

	





	

		

			

				
					
golang 笔记

				
			

			

				

					dly667的博客
				

				

					12-05
					
					136
					
				

			

		

		

			
				

快速读取文件

fi, err := os.Open(path)
if err != nil {
	panic(err)
}
defer fi.Close()
fd, err := ioutil.ReadAll(fi)  //[]byte


os 包的用法


os.Getwd() 当前文件路径的字符串和一个err信息
os.Chdir() 将当前文件路径改变为目标路径（非真实改变）
os.G...

			
		

	





	

		

			

				
					

				
			

			

				

					
				

			

		

		

			
				

			
		

	



              




          




        



    





    



      

      

        
      

      





	

		评论	
	

	
	




  

    

      添加红包
      
    

    

      

        
        

          
          
        

        
请填写红包祝福语或标题

      

      

        
        

          
          个
        

        
红包个数最小为10个

      

      

        
        

          
          元
        

        
红包金额最低5元

      

      

        
        

          当前余额3.43元
          前往充值 >
        

      

      

        

          需支付：10.00元
        

        
        
      

    

  





  

    
    
  

  

    
    
  








  

    

      

        

          

            
            
成就一亿技术人!

          

          

        

        

          

          

            领取后你会自动成为博主和红包主的粉丝
            规则
          

        

      

      

        

          

            
              
            
            

              
hope_wisdom
 发出的红包
            

          

        

        

          

          

          

        

      

    

    

  



      
      

      
实付元

      
使用余额支付

      

        

          

            
            点击重新获取
          

        

        
扫码支付

      

      

        
          
            
          
          
        
      

      

        
        钱包余额
          0
          

            
            

              

                
抵扣说明：

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

              

            

          

      

      余额充值