1 / 20

Debugging Your (Threaded) Proxy

Learn good programming and debugging practices, tips for designing and testing your proxy, and a tool for testing your multi-threaded proxy.

jessiee
Download Presentation

Debugging Your (Threaded) Proxy

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 15-213: How to dBug your (threaded) proxy Jiří Šimša PARALLEL DATA LABORATORY Carnegie Mellon University

  2. Motivation http://www.pdl.cmu.edu/ “Concurrency is a good servant but a bad master” • Today we will cover: • good programming practices • good debugging practices • tips for designing and testing your proxy • a tool for testing your multi-threaded proxy

  3. Before We Start http://www.pdl.cmu.edu/ • Go to: http://www.virtualbox.org/ and download and install VirtualBox on your laptop • Go to: http://www.cs.cmu.edu/~213/resources.html and start downloading the dbug-213.vdi

  4. GOOD programming PRACTICES http://www.pdl.cmu.edu/

  5. 1. Know Your Library Calls Spending time reading a man page will dispel your misconceptions and save you hours of frustration. http://www.pdl.cmu.edu/ ... pthread_mutex_lock(&mutex); if (cache_empty()) { pthread_mutex_unlock(&mutex); ... } ... pthread_mutex_unlock(&mutex); ...

  6. 2. Check Return Values Handling error cases correctly will facilitate identification of program failure root cause. http://www.pdl.cmu.edu/ ... ret = accept(sockfd,addr,addrlen); if (ret == -1) { perror(“Accept failed.\n”); } else { ... } ... assert(pthread_mutex_lock(&mutex) == 0); ...

  7. 3. Use Conditional Compilation Spending time including informative messages will greatly improve your debugging efficiency. http://www.pdl.cmu.edu/ void * request_handler(void *args) { #ifdef DEBUG printf(“Entering %s”, __FUNCTION__); #endif ... } $ gcc –DDEBUG ...

  8. 4. Learn and Use Makefiles Spending time learning how to use a Makefile will save you hours of repetitive and dull work. http://www.pdl.cmu.edu/ CC = gcc CFLAGS = -g -Wall -Werror LDFLAGS = -lpthread ... all: proxy proxy-test proxy: proxy.ccsapp.c $(CC) -o $@ $(CFLAGS) -O3 $(LDFLAGS) $^ proxy-test: proxy.ccsapp.c $(CC) -o $@ $(CFLAGS) -DDEBUG $(LDFLAGS) $^

  9. 5. Keep It Simple (Silly) Start with the simplest approach possible. Often getting the simplest design right will be enough. http://www.pdl.cmu.edu/ ... int main(intargc, char *argv[]) { ... init_proxy(); while(1) { if ((ret = accept(sockfd,addr,addrlen)) > 0) { setup_args(sockfd,addr,addrlen,args); ret = pthread_create(&tid, 0, handler, args); assert(ret == 0); } else { perror(“Accept failed.\n”); } } }

  10. 6. Avoid Premature Optimizations Start with the simplest approach possible. Often getting the simplest design right will be enough. http://www.pdl.cmu.edu/ ... // All cache operations take O(1) time. Sick! fancy_cache_t cache; ... inline void lookup_cache_entry(structcache_entry *entry) { ... // 100+ lines of code ... }

  11. 7. Learn and Use gdb Learning how to control and inspect execution of a program is instrumental to efficient debugging. http://www.pdl.cmu.edu/ $ ulimit -c unlimited $ ./proxy 1234 Segmentation fault (core dumped) $ gdb ./proxy core ... (gdb) bt ... #3 0x08049865 in doit (fd=4) at proxy.c:179 #4 0x080496c5 in thread_handler (connfdp=0x9920008) at proxy.c:136 #5 0x00da7cc9 in start_thread (arg=0xb78adb70) at pthread_create.c:304 ...

  12. Summary of Good Practices http://www.pdl.cmu.edu/ Know Your Library Calls Check Return Values Use Conditional Compilation Learn and Use a Makefile Keep it Simple Avoid Premature Optimization Learn and Use gdb

  13. Testing Your Proxy http://www.pdl.cmu.edu/

  14. Sequential Proxy Test Case http://www.pdl.cmu.edu/ Open three terminal windows 1:$ cd $TINY; make; sudo ./tiny 80 2:$ cd $PROXY; make; ./proxy 1234 3:$ curl –x localhost:1234 http://localhost  <html> <head><title>test</title></head> <body> <img align="middle" src="godzilla.gif"> Dave O'Hallaron </body> </html>

  15. Case Proxy Test Case http://www.pdl.cmu.edu/ Open three terminal windows 1:$ cd $TINY; make; sudo ./tiny 80 2:$ cd $PROXY; make; ./proxy 1234 3:$ curl –x localhost:1234 HTTP://LoCaLhOst  <html> <head><title>test</title></head> <body> <img align="middle" src="godzilla.gif"> Dave O'Hallaron </body> </html>

  16. Port Proxy Test Case http://www.pdl.cmu.edu/ Open three terminal windows 1:$ cd $TINY; make; ./tiny 8080 2:$ cd $PROXY; make; ./proxy 1234 3:$ curl –x localhost:1234 http://localhost:8080  <html> <head><title>test</title></head> <body> <img align="middle" src="godzilla.gif"> Dave O'Hallaron </body> </html>

  17. Cache Proxy Test Case http://www.pdl.cmu.edu/ Open three terminal windows 1:$ cd $TINY; make; sudo ./tiny 80 2:$ cd $PROXY; make; ./proxy 1234 3:$ curl –x localhost:1234 http://localhost 3:$ killall -9 tiny 3:$ curl –x localhost:1234 http://localhost <html> <head><title>test</title></head> <body> <img align="middle" src="godzilla.gif"> ...

  18. Concurrent Proxy Test Case http://www.pdl.cmu.edu/ Open three terminal windows 1:$ cd $TINY; make; sudo ./tiny 80 2:$ cd $PROXY; make; ./proxy 1234 3:$ export CMD=“curl –x localhost:1234 http://localhost” 3:$ $CMD & $CMD Which request will get serviced 1st? Will the 2nd request be serviced from cache? Will a non-reentrant function be called concurrently? How to try out all possible cases?

  19. USING DBUG http://www.pdl.cmu.edu/

  20. dBug: Concurrent gdb and more http://www.pdl.cmu.edu/ Systematic Testing of Concurrent Systems Given a concurrent system and a test, dBug systematically explores all possible ways in which the test could have executed dBug searches for deadlocks, data races, and assertion violations

More Related