복제 할 수없는 버그를 어떻게 수정합니까?

복제 할 수없는 버그를 어떻게 수정합니까?

---

질문은 모든 것을 말해줍니다. 여러 사용자가보고하는 버그가 있지만 로그에 발생한 버그 기록이없고 아무리 노력해도 버그가 반복 될 수없는 경우 어떻게 해결합니까? 아니면 할 수 있습니까?

나는 이것이 많은 사람들에게 일어났다 고 확신합니다. 이 상황에서 무엇을했으며 최종 결과는 무엇입니까?

---

편집 : 내가 대해 이루어졌다 것에 더 관심이 unfindable 버그가 아니라 해석되지 않는 버그가 수정되었습니다. 해결할 수없는 버그는 적어도 문제가 있음을 알고 있으며 대부분의 경우 검색을위한 시작점이 있습니다. 찾을 수없는 경우 어떻게합니까? 당신은 아무것도 할 수 있습니까?

---

이들은 Heisenbugs 로 알려져 있습니다 .

언어

프로그래밍 언어마다 고유 한 버그가 있습니다.

씨

디버그 문을 추가 하면 디버그 문 자체가 포인터를 이동하기 때문에 문제 를 복제 할 수 없게됩니다 (SEGFAULT를 피하기에 충분 함). 포인터 문제는 추적하고 복제하기에는 악몽이지만 도움이 될 수 있는 디버거 (예 : GDB 및 DDD )가 있습니다.

자바

여러 스레드가있는 응용 프로그램은 매우 특정한 타이밍 또는 이벤트 시퀀스로만 버그를 표시 할 수 있습니다. 부적절한 동시성 구현은 복제하기 어려운 상황에서 교착 상태를 일으킬 수 있습니다.

자바 스크립트

일부 웹 브라우저는 메모리 누수로 악명이 높습니다. 한 브라우저에서 제대로 실행되는 JavaScript 코드는 다른 브라우저에서 잘못된 동작을 일으킬 수 있습니다. 수천 명의 사용자가 엄격하게 테스트 한 타사 라이브러리를 사용하면 모호한 특정 버그를 방지 할 수 있습니다.

환경

버그가있는 애플리케이션이 실행되는 환경의 복잡성에 따라 유일한 해결책은 환경을 단순화하는 것입니다. 응용 프로그램이 실행됩니까?

• 서버에서?
• 데스크탑에서?
• 웹 브라우저에서?

응용 프로그램이 어떤 환경에서 문제를 생성합니까?

• 개발?
• 테스트?
• 생산?

관련없는 응용 프로그램을 종료하고, 백그라운드 작업을 종료하고, 예약 된 모든 이벤트 (cron 작업)를 중지하고, 플러그인을 제거하고, 브라우저 추가 기능을 제거합니다.

네트워킹

네트워킹은 매우 많은 애플리케이션에 필수적이므로 :

• 무선 신호를 포함하여 안정적인 네트워크 연결을 보장합니다.
• 네트워크 장애가 발생한 후 소프트웨어가 다시 연결됩니까?
• 파일 설명자를 해제하기 위해 모든 연결이 제대로 닫히나요?
• 해서는 안되는 기계를 사용하는 사람들이 있습니까?
• 불량 장치가 시스템의 네트워크와 상호 작용하고 있습니까?
• 간섭을 일으킬 수있는 공장이나 라디오 타워가 근처에 있습니까?
• 패킷 크기와 주파수가 공칭 범위 내에 있습니까?
• 모든 네트워크 장치가 과도한 대역폭 사용에 적합합니까?

일관성

가능한 한 많은 알려지지 않은 항목을 제거하십시오.

• 건축 구성 요소를 분리합니다.
• 중요하지 않거나 문제가 될 수있는 (충돌하는) 요소를 제거합니다.
• 다른 애플리케이션 모듈을 비활성화합니다.

프로덕션, 테스트 및 개발 간의 모든 차이점을 제거하십시오. 동일한 하드웨어를 사용하십시오. 컴퓨터를 설정하려면 똑같은 단계를 완벽하게 따르십시오. 일관성이 핵심입니다.

벌채 반출

이벤트가 발생한 시간을 연관시키기 위해 충분한 양의 로깅을 사용하십시오. 명백한 오류, 타이밍 문제 등이 있는지 로그를 검사합니다.

하드웨어

소프트웨어가 정상인 것 같으면 하드웨어 결함을 고려하십시오.

• 물리적 네트워크 연결이 견고합니까?
• 느슨한 케이블이 있습니까?
• 칩이 제대로 장착되어 있습니까?
• 모든 케이블이 깔끔하게 연결되어 있습니까?
• 작업 환경이 깨끗하고 먼지가 없습니까?
• 설치류 나 곤충에 의해 숨겨진 장치 나 케이블이 손상 되었습니까?
• 드라이브에 불량 블록이 있습니까?
• CPU 팬이 작동합니까?
• 마더 보드가 모든 구성 요소에 전원을 공급할 수 있습니까? (CPU, 네트워크 카드, 비디오 카드, 드라이브 등)
• 수 전자기 간섭이 범인 일?

그리고 대부분 임베디드 :

• 부족한 공급 우회?
• 보드 오염?
• 솔더 조인트 불량 / 리플 로우 불량?
• 공급 전압이 허용 범위를 벗어나면 CPU가 재설정되지 않습니까?
• 공급 레일이 I / O 포트에서 다시 전원이 공급되고 완전히 방전되지 않기 때문에 잘못된 재설정이 있습니까?
• 래치 업?
• 플로팅 입력 핀?
• 로직 레벨에서 불충분 한 (때로는 부정적인) 노이즈 마진이 있습니까?
• 불충분 한 (때때로 부정적) 타이밍 마진?
• 주석 수염 ?
• ESD 손상?
• ESD 화가?
• 칩 정오표?
• 인터페이스 오용 (예 : I2C 오프 보드 또는 고전력 신호 존재)?
• 경쟁 조건?
• 위조 부품?

네트워크 대 로컬

응용 프로그램을 로컬로 (즉, 네트워크를 통하지 않고) 실행하면 어떻게됩니까? 다른 서버에도 동일한 문제가 발생합니까? 데이터베이스가 원격입니까? 로컬 데이터베이스를 사용할 수 있습니까?

펌웨어

하드웨어와 소프트웨어 사이에는 펌웨어가 있습니다.

• 컴퓨터 BIOS가 최신입니까?
• BIOS 배터리가 작동합니까?
• BIOS 시계와 시스템 시계가 동기화되어 있습니까?

시간과 통계

타이밍 문제는 추적하기 어렵습니다.

• 문제가 언제 발생합니까?
• 얼마나 자주?
• 그 당시 실행중인 다른 시스템은 무엇입니까?
• 응용 프로그램이 시간에 민감합니까 (예 : 윤일 또는 윤초로 인해 문제가 발생합니까)?

문제에 대한 정확한 수치 데이터를 수집하십시오. 처음에는 무작위로 보일 수있는 문제에 실제로 패턴이있을 수 있습니다.

변경 관리

시스템 업그레이드 후 때때로 문제가 나타납니다.

• 문제가 언제 처음 시작 되었습니까?
• 환경 (하드웨어 및 소프트웨어)에서 변경된 사항은 무엇입니까?
• 이전 버전으로 롤백하면 어떻게됩니까?
• 문제가있는 버전과 좋은 버전 사이에 어떤 차이점이 있습니까?

도서관 관리

운영 체제마다 충돌하는 라이브러리를 배포하는 방법이 다릅니다.

• Windows에는 DLL Hell이 있습니다.
• Unix는 여러 개의 깨진 심볼릭 링크를 가질 수 있습니다.
• 자바 라이브러리 파일도 마찬가지로 악몽처럼 해결할 수 있습니다.

운영 체제를 새로 설치하고 응용 프로그램에 필요한 지원 소프트웨어 만 포함합니다.

자바

모든 라이브러리가 한 번만 사용되는지 확인하십시오. 때때로 애플리케이션 컨테이너에는 애플리케이션 자체와 다른 버전의 라이브러리가 있습니다. 이것은 개발 환경에서 복제가 불가능할 수 있습니다.

Maven 또는 Ivy 와 같은 라이브러리 관리 도구를 사용합니다 .

디버깅

버그가 발생하면 알림 (예 : 로그, 이메일, 팝업, 호출기 경고음)을 트리거하는 탐지 방법을 코딩합니다. 자동화 된 테스트를 사용하여 애플리케이션에 데이터를 제출합니다. 무작위 데이터를 사용하십시오. 알려진 및 가능한 엣지 케이스를 다루는 데이터를 사용합니다. 결국 버그가 다시 나타납니다.

자다

It is worth reiterating what others have mentioned: sleep on it. Spend time away from the problem, finish other tasks (like documentation). Be physically distant from computers and get some exercise.

Code Review

Walk through the code, line-by-line, and describe what every line does to yourself, a co-worker, or a rubber duck. This may lead to insights on how to reproduce the bug.

Cosmic Radiation

Cosmic Rays can flip bits. This is not as big as a problem in the past due to modern error checking of memory. Software for hardware that leaves Earth's protection is subject to issues that simply cannot be replicated due to the randomness of cosmic radiation.

Tools

Infrequent but it happens, especially for niche tools (e.g. a C micro-controller compiler suffering from a symbol table overflow).

---

If it's a GUI app, it's invaluable to watch the customer generate the error (or try to). They'll no doubt being doing something you'd never have guessed they were doing (not wrongly, just differently).

Otherwise, concentrate your logging in that area. Log most everything (you can pull it out later) and get your app to dump its environment as well. e.g. machine type, VM type, encoding used.

Does your app report a version number, a build number, etc.? You need this to determine precisely which version you're debugging (or not!).

If you can instrument your app (e.g. by using JMX if you're in the Java world) then instrument the area in question. Store stats e.g. requests+parameters, time made, etc. Make use of buffers to store the last 'n' requests/responses/object versions/whatever, and dump them out when the user reports an issue.

---

If you can't replicate it, you may fix it, but can't know that you've fixed it.

I've made my best explanation about how the bug was triggered (even if I didn't know how that situation could come about), fixed that, and made sure that if the bug surfaced again, our notification mechanisms would let a future developer know the things that I wish I had known. In practice, this meant adding log events when the paths which could trigger the bug were crossed, and metrics for related resources were recorded. And, of course, making sure that the tests exercised the code well in general.

Deciding what notifications to add is a feasability and triage question. So is deciding on how much developer time to spend on the bug in the first place. It can't be answered without knowing how important the bug is.

I've had good outcomes (didn't show up again, and the code was better for it), and bad (spent too much time not fixing the problem, whether the bug ended up fixed or not). That's what estimates and issue priorities are for.

---

Sometimes I just have to sit and study the code until I find the bug. Try to prove that the bug is impossible, and in the process you may figure out where you might be mistaken. If you actually succeed in convincing yourself it's impossible, assume you messed up somewhere.

It may help to add a bunch of error checking and assertions to confirm or deny your beliefs/assumptions. Something may fail that you'd never expect to.

---

It can be difficult, and sometimes near impossible. But my experience is, that you will sooner or later be able to reproduce and fix the bug, if you spend enough time on it (if that spent time is worth it, is another matter).

General suggestions that might help in this situation.

• Add more logging, if possible, so that you have more data the next time the bug appears.
• Ask the users, if they can replicate the bug. If yes, you can have them replicate it while watching over their shoulder, and hopefully find out, what triggers the bug.

---

Make random changes until something works :-)

---

Think. Hard. Lock yourself away, admit no interuptions.

I once had a bug where the evidence was a hex dump of a corrupt database. The chains of pointers were systematically screwed up. All the user's programs, and our database software, worked faultlessly in testing. I stared at it for a week (it was an important customer), and after eliminating dozens of possible ideas, I realised that the data was spread across two physical files and the corruption occurred where the chains crossed file boundaries. I realized that if a backup/restore operation failed at a critical point, the two files could end up "out of sync", restored to different time points. If you then ran one of the customer's programs on the already-corrupt data, it would produce exactly the knotted chains of pointers I was seeing. I then demonstrated a sequence of events that reproduced the corruption exactly.

---

modify the code where you think the problem is happening, so extra debug info is recorded somewhere. when it happens next time, you will have what your need to solve the problem.

---

There are two types of bugs you can't replicate. The kind you discovered, and the kind someone else discovered.

If you discovered the bug, you should be able to replicate it. If you can't replicate it, then you simply haven't considered all of the contributing factors leading towards the bug. This is why whenever you have a bug, you should document it. Save the log, get a screenshot, etc. If you don't, then how can you even prove the bug really exists? Maybe it's just a false memory?

If someone else discovered a bug, and you can't replicate it, obviously ask them to replicate it. If they can't replicate it, then you try to replicate it. If you can't replicate it quickly, ignore it.

I know that sounds bad, but I think it is justified. The amount of time it will take you to replicate a bug that someone else discovered is very large. If the bug is real, it will happen again naturally. Someone, maybe even you, will stumble across it again. If it is difficult to replicate, then it is also rare, and probably won't cause too much damage if it happens a few more times.

You can be a lot more productive if you spend your time actually working, fixing other bugs and writing new code, than you will be trying to replicate a mystery bug that you can't even guarantee actually exists. Just wait for it to appear again naturally, then you will be able to spend all your time fixing it, rather than wasting your time trying to reveal it.

---

Assuming you have already added all the logging that you think would help and it didn't... two things spring to mind:

1. Work backwards from the reported symptom. Think to yourself.. "it I wanted to produce the symptom that was reported, what bit of code would I need to be executing, and how would I get to it, and how would I get to that?" D leads to C leads to B leads to A. Accept that if a bug is not reproducible, then normal methods won't help. I've had to stare at code for many hours with these kind of thought processes going on to find some bugs. Usually it turns out to be something really stupid.

2. Remember Bob's first law of debugging: if you can't find something, it's because you're looking in the wrong place :-)

---

Discuss the problem, read code, often quite a lot of it. Often we do it in pairs, because you can usually eliminate the possibilities analytically quite quickly.

---

Start by looking at what tools you have available to you. For example crashes on a Windows platform go to WinQual, so if this is your case you now have crash dump information. Do you can static analysis tools that spot potential bugs, runtime analysis tools, profiling tools?

Then look at the input and output. Anything similar about the inputs in situations when users report the error, or anything out of place in the output? Compile a list of reports and look for patterns.

Finally, as David stated, stare at the code.

---

Ask user to give you a remote access for his computer and see everything yourself. Ask user to make a small video of how he reproduces this bug and send it to you.

Sure both are not always possible but if they are it may clarify some things. The common way of finding bugs are still the same: separating parts that may cause bug, trying to understand what`s happening, narrowing codespace that could cause the bug.

---

There are tools like gotomeeting.com, which you can use to share screen with your user and observe the behaviour. There could be many potential problems like number of softwares installed on their machines, some tools utility conflicting with your program. I believe gotomeeting, is not the only solution, but there could be timeout issues, slow internet issue.

Most of times I would say softwares do not report you correct error messages, for example, in case of java and c# track every exceptions.. dont catch all but keep a point where you can catch and log. UI Bugs are difficult to solve unless you use remote desktop tools. And most of time it could be bug in even third party software.

---

If you work on a real significant sized application, you probably have a queue of 1,000 bugs, most of which are definitely reproducible.

Therefore, I'm afraid I'd probably close the bug as WORKSFORME (Bugzilla) and then get on fixing some more tangible bugs. Or doing whatever the project manager decides to do.

Certainly making random changes is a bad idea, even if they're localised, because you risk introducing new bugs.

참고URL : https://stackoverflow.com/questions/1268373/how-do-you-fix-a-bug-you-cant-replicate