valgrind가있는 G-WAN? 대안?

Question

G-WAN은 out-of-the-box에서 C 코드를 실행할 수있는 편리한 방법이지만 valgrind에서는 작동하지 않습니다. (valgrind ./gwan을 실행하면 오류 메시지 Inconsistency detected by ld.so: rtld.c: 1292: dl_main: Assertion `_rtld_local._dl_rtld_map.l_libname' failed!가 발생하고 종료되며 시스템은 Debian Jessie 64bit입니다.

질문 :
1) G-WAN이 valgrind와 함께 작동해야합니까?
2) G-WAN에서 실행중인 C 코드의 메모리 버그를 감지 할 수있는 다른 가능한 옵션이 있습니까?

Answer 1

G-WAN은 valgrind와 함께 작동합니까?

우리는 Valgrind를 테스트했으며 많은 작업을 수행하는 동안 높은 동시성 작업에는 적합하지 않습니다 (낮은 동시성이 Valgrind에서 문제가 있음).

G-WAN에서 실행되는 C 코드의 메모리 버그를 감지 할 수있는 실행 가능한 옵션은 무엇입니까?

사용 malloc() 래퍼, 사전 할당 된 풀, 또는 더 나은, 처음에 메모리 문제가 발생하지 않도록 alloca()를 사용합니다. G-WAN 서버를 충돌없이 C 스크립트에서 잘못된 포인터를 처리하는

참고, 참조 : http://gwan.ch/developers#crash

이 버그 코드 :

int main(int argc, char *argv[]) 
{ 
    strcpy(0xBADC0DE, 0xBADC0DE); 
    return 200; 
} 

은 ... 다음 '우아한'처럼 뭔가를 생성합니다 충돌 보고서 :

Script: crash_libc.c 
Client: 127.0.0.1 
Query : ?crash_libc 

Signal  : 11:Address not mapped to object 
Signal src : 1:SEGV_MAPERR 
errno   : 0 
Thread  : 0 
Code Pointer: 0000f5200b33 (module:/lib/libc.so.6, function:strcpy, line:0) 
Access Address: 00000badc0de 

Registers  : EAX=00000badc0de CS=00000033 EIP=0000f5200b33 EFLGS=000000010202 
       EBX=000000000001 SS=ec2d8ed4 ESP=0000f5ded828 EBP=0000f5dee020 
       ECX=000033323130 DS=ec2d8ed4 ESI=0000ec2d8f86 FS=00000033 
       EDX=000003b03c00 ES=ec2d8ed4 EDI=00000badc0de CS=00000033 

Module  :Function  :Line # PgrmCntr(EIP) RetAddress FramePtr(EBP) 
     libc.so.6:   strcpy:  - 0000f5200b33 0000ec2d8f00 0000f5dee020 
     servlet:   main: 37 0000ec2d8f00 00000042e10c 0000f5dee020   

그리고 G-WAN 버그합니다 (G-WAN의 crash_xxx.c의 예 참조) instea 소스 코드에서 일어난 위치를 당신에게로까지 간다 d는 서버 프로세스를 종료합니다.

C 코드를 디버깅하지 않으려면 Java 또는 Scala (둘 다 G-WAN에서 지원됨)를 사용하십시오. GC가 모든 것이 느려져 무료가 될 때까지 데이터가로드 된 상태로 유지되므로 훨씬 더 많은 메모리가 필요합니다. 그것이 해제 될 수 있다고 생각하는 - 적어도 당신은 메모리 관련 버그가 있다면, 그것보다 적게 즐길 것입니다.

---

질문하는 사람의 요청에 따라 여기에 자세한 내용이 나와 있습니다.

2012 년 하반기에 Valgrind처럼 동시성 디버깅에 도움이되는 12 개의 무료 상용 도구를 테스트했습니다. 또한 실행중인 (컴파일 된) 프로그램에서 작동하는 동적 도구뿐만 아니라 소스 코드를 연구하는 정적 도구도 사용했습니다.

슬픈 사실은 그들은 모두 일반적인 문제로 고통이다 :

• 는 일반적으로 동시성 (핵심 문제)
• 생산 사소한 경고의 gazillions (그리고 더 많은 거짓 경보를 지원하기에 너무 느리다)
• 은 매우 비쌉니다. 물론 구매하기 전에 테스트 할 수는 없습니다.)

그래서 확인하고 모든 결과를 필터링 주 후에, 우리는 구별 할 수 없습니다 도구에 의한 사소한 거짓 경고 (경고를 제거하기 위해 G-WAN 코드베이스를 "수정"많은 시간을 보냈습니다 버그 코드의 유효한 코드) ... 그러나 당시 우리는 당황 스럽지만 G-WAN의 실제 버그를 발견하지 못했습니다 (그 주간은 시간 낭비 였음을 분명히합니다).

위의 결론은 가능한 경우 간단한 코드를 작성하고보다 정교한 전략이 필요할 때 블록을 미리 할당 해보십시오.

물론 리눅스 LIBC가 (붙잡을 수없는) abort 신호로 응용 프로그램을 죽이려한다고해서 도움이되지 않습니다 (프로그램이 복구되지 않거나 관련 추적을 덤프하지 못하게합니다). 특히 부주의 한 이중 자유 Linux LIBC 탐지 (프로그램이 malloc()을 한 번 사용했을 때 모든 코드가 malloc()을 사용한다고 잘못 가정 함 - 이는 LIBC 호출에 의해 종종 수행됩니다!). 그리고 mmap() 실패 나 OOM kill-switch에 대해서도 언급하고 있지 않습니다.

우리가 지금까지 연구 한 유일한 해결책은 Linux LIBC 사용을 피하고 우리 자신의 C 런타임에서 필요한 모든 것을 컴파일하는 것입니다. 모든 사용자에 대해 "할 일"을으로 추천하기는 다소 어려웠지만 우리에게는 효과가있었습니다.

Linux에서 사용하는 코드의 일부 (또는 G-WAN에서 구현 된 개념 중 일부)를 보게되어 매우 기쁩니다. 이렇게하면 우리의 삶 (그리고 다른 많은 개발자들 중 하나)이 훨씬 쉽게 그러나 우리가 과거에 "책임자"와 가진 접촉은 격려가되지 않았다.

모두가 OS와 ISV, 개발자와 같은 개선의 여지가 있습니다. 결국 동시성은 2004 년 이래로 단지 "주류"입니다. 거의 10 년 전.