关于硬盘满了导致的bug

在测试的过程中，我们往往会遇到很多稀奇古怪的bug，而研发有时一时半会也找不到原因，往往是基于我们之前的测试经验，来迅速排查问题。

1、在刚开始进入测试行业不久的时候，遇到一个问题，在服务器端，抓包发现每次抓的包都是无数据，刚开始排查的原因是语句出错，其实不然，发现在home下，挂的盘满了，导致无法存储数据

2、在参加项目是，也遇到一个同样的问题。搜人的项目，查看日志，都发现没有任何的异常，但是处理的图片没有保存，并且在数据库也没有保存图片的路径，依据经验，硬盘空间满了，df -h 看了一下，证实猜测，新挂载了一个盘，问题解决！

原文地址：https://www.cnblogs.com/Good-Life/p/9069030.html

时间： 2024-10-31 01:15:51

关于硬盘满了导致的bug的相关文章

对非正确使用浮点型数据而导致项目BUG的问题探讨

乘法分配律 在上小学的时候就已经学习过乘法分配律,乘法分配律的具体内容是:两个数的和与一个数相乘,可以先把他们分别与这个数相乘,再相加,得数不变.乘法分配律的定义还可以用表达式"(a+b)×c = a×c+b×c"的形式给出.乘法分配律的反用"a×c+b×c = (a+b)×c"同样成立.例如"10.2×(3+7) = 10.2×3+10.2×7 = 102"(反用形式为"10.2×3+10.2×7 = 10.2×(3+7) = 102

C++随机数导致的bug

这周我在写path tracing的时候遇到了一个很奇怪的bug:光线追踪深度设为1的时候结果看起来是正常的,但是深度高于1的时候就会出现很奇怪的渲染结果,如下图所示(为了便于调试,我用了一个cornell-box的场景,mesh的颜色是统一的,并且设置的只是点光源): 我仔细排查了逻辑上的代码,并没有发现几何计算.光照计算等模块有明显的问题(如果有问题,应该在depth为1的时候就测试出来了).这时我观察到,这个颜色呈现出"一块一块"的表现,我猜测可能是由于在光线做完第一次碰撞后,利

iptables的conntrack表满了导致访问网站很慢

现象:突然发现访问网站很慢,服务器的cpu.内存和磁盘使用率都正常 分析过程及解决方案:查询/var/log/message日志发现有这样的记录“ip_conntrack table full dropping packet”.kernel 用 ip_conntrack 模块来记录 iptables 网络包的状态,并保存到 table 里(这个 table 在内存里),如果网络状况繁忙,比如高连接,高并发连接等会导致逐步占用这个 table 可用空间,一般这个 table 很大不容易占满并且可以

结构体类型重声明导致的bug一个

bug前提条件 当模块比较多,头文件较多,某个结构体类型会在当前模块中重新声明进而引用其成员,而不直接包含其他模块的头文件.这样的好处是不引入不需要的类型声明到此模块,头文件包含的交叉:坏处是,增加了bug的几率,耦合太大!比如下面一种情况发生而导致bug: 已知两个模块A和B,同一个结构类型struct node在两个模块中分别声明,其中B模块无意或者有意调整了结构类型中的某些域.那么这个时候,若B模块中引用A模块中此类型实例然后访问成员变量,就会引发bug!如下重现示例 bug重新示例代码

在docker以FPM-PHP运行php，慢日志导致的BUG分析

问题描述: 最近将IOS书城容器化,切换流量后.正常的业务测试了一般,都没发现问题.线上的错误监控系统也没有报警,以为迁移工作又告一段落了,暗暗的松了一口气.紧接着,报警邮件来了,查看发现是一个苹果支付相关接口调用的curl错误,错误码为"56",错误描述为:“Failure with receiving network data”接收网络数据失败. 机器 : 192.168.1.1当前URL : /xxx/recharge/apple?xxxxxxxxxxxxx接口URL : htt

高并发压力下导致数据库bug

环境信息:  linux 6.1 + oracle11.2.0.3 RAC 问题现象: 学校晚上6点选课,人数大概有3000,7点时,数据库报错如下(数据库到6点多还是可以连接的),数据库hung住了. Tue Dec 16 18:00:33 2014Dumping diagnostic data in directory=[cdmp_20141216180033], requested by (instance=2, osid=24917 (M001)), summary=[incident=

Oracle归档日志满了导致Oracle连接(ORA-00257)报错处理

最近一段时间,有收到一台Oracle服务器的连接告警, 刚刚开始还以为是Oracle的监听被关闭导致,结果连上服务器看下Oracle的监听进程正常,自己连接一次发现有报ORA-00257错,又去监控系统中在看下日志再用sqlplus连上Oracle后查了下,知道是Oracle的归档日志写满闪回区导致Oracle连接异常,查看归档日志方法如下: SQL> show parameter db_recovery_file_dest; #查看归档日志的物理路径及闪回区的大小 SQL> select f

PHP 数组 foreach引用导致的bug

<?php $arr = array('a', 'b', 'c'); foreach($arr as &$v) {} foreach($arr as $v) {} var_dump($arr); /* 结果为: array(3) { [0]=> string(1) "a" [1]=> string(1) "b" [2]=> &string(1) "b" } */ //第一个foreach用引用赋值的方式将数

一次疏忽导致的bug

NBB_PUT_SHORT 这个宏是按char* 类型算指针的实际工作中,没有注意这一点,输入指针类型 强转为了 SHORT* 导致 填充的内容错误 这是第一次在工作中遇到 指针类型相关的问题值得记录一笔 1 // ConsoleApplication1.cpp : 定义控制台应用程序的入口点. 2 // 3 4 #include "stdafx.h" 5 #include <stdio.h> 6 #include <string.h> 7 #include &