Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Debugging file corruption on iOS

code.facebook.com

Post reply on HN
Print view View original

11–20 of 22 posts

Re: Debugging file corruption on iOS

#11

Post by nspiegelberg »

SoftwareMaven wrote: post #6

This is the challenge of modern software development. When I first started my career, I spent two months looking for a random crashing bug in a video game due to misplaced free(); this was in code that was 100% ours. Now, there likely isn't an application in existence that does anything interesting where 100% of the code was written for the app itself. As such, you are no longer debugging your own code, but other peo…

I chatted with Wired about just this concept: http://www.wired.com/2014/08/facebook_bug/

Re: Debugging file corruption on iOS

#14

Post by general_failure »

nspiegelberg wrote: post #11
SoftwareMaven wrote: post #6

This is the challenge of modern software development. When I first started my career, I spent two months looking for a random crashing bug in a video game due to misplaced free(); this was in code that was 100% ours. Now, there likely isn't an application in existence that does anything interesting where 100% of the code was written for the app itself. As such, you are no longer debugging your own code, but other peo…

I chatted with Wired about just this concept: http://www.wired.com/2014/08/facebook_bug/

No offense to you but that article is very poorly written. It seems like someone abducted the author mid-article and pressed the publish button :)

Re: Debugging file corruption on iOS

#15

Post by codemac »

SoftwareMaven wrote: post #6

This is the challenge of modern software development. When I first started my career, I spent two months looking for a random crashing bug in a video game due to misplaced free(); this was in code that was 100% ours. Now, there likely isn't an application in existence that does anything interesting where 100% of the code was written for the app itself. As such, you are no longer debugging your own code, but other peo…

Interestingly, in my first job all of the code I worked on my first 3 years was all "in-house" code (because from the bootloader to my code was all proprietary). I think places like Microsoft also have groups that have the same phenomenon. However - the people who initially wrote or worked on that code were long gone.

I've gone on to work other places where I had to do more of this archeology.. and I have to say it actually felt similar.

In summary - I think there is actually a new, more combinatorially complex amount of archeology occurring now. Where the microsoft, apple, netapp, linux, emc, vxworks, etc OS people have been dealing with some of this for a while with one OS... people who rely on services, on many processes, on an internet of things or whatever..

It feels like we'll never have a POSIX of the internet. HTTP is as close as we've gotten, and it's too small to be read/write/exec. We'll never have anything you can "trust" and more and more developers need the patience to wade through everyone else's code as well.

Re: Debugging file corruption on iOS

#16

Post by dcsommer »

pretz wrote: post #2

> "The SSL layer instead handled a raw file descriptor and, consequently, lifetime handling was not automatically synchronized ... We worked with the networking team and fixed this issue within hours." Why on earth is Facebook writing their own SSL layer for iOS?

Stock SSL on iOS doesn't have NPN, which is needed to negotiate SPDY on the internet.

Re: Debugging file corruption on iOS

#17

Post by fdawg4l » 

  > // setup a honeypot file
  > int trap_fd = open(…); 
  > // Create new function to detect writes to the honeypot
  > static WRITE_FUNC_T original_write = dlsym(RTLD_DEFAULT, "write");;
  > ssize_t corruption_write(int fd, const void *buf, size_t size) { 
  >   FBFatal(fd != trap_fd, @"Writing to the honeypot file");
  > }
  > return original_write(fd, buf, size);
  > }
  > // Replace the system write with our “checked version”
  > rebind_symbols((struct rebinding[1]){{(char *)"write", (void *)corruption_write}}, 1);
Does this code snippet look fishy to anyone else? First, the mismatch braces are messing with my head. I'm thinking the brace before the return is a typo. Also, the call to the macro looks wrong. Shouldn't they be checking for fd == trap_fd?

Re: Debugging file corruption on iOS

#18

Post by nspiegelberg »

general_failure wrote: post #14
nspiegelberg wrote: post #11

Earlier quoted context omitted.

I chatted with Wired about just this concept: http://www.wired.com/2014/08/facebook_bug/

No offense to you but that article is very poorly written. It seems like someone abducted the author mid-article and pressed the publish button :)

There are some technical inaccuracies that make it hard to look past as a coder (mixing up POSIX and UNIX, talking about unexpected behavior as a bug). However, I think the author did an accurate job on the high-level tenor of the article and touched on a critical meta-point about this bug.

Re: Debugging file corruption on iOS

#19

Post by lutusp »

fdawg4l wrote: post #17

> // setup a honeypot file > int trap_fd = open(…); > // Create new function to detect writes to the honeypot > static WRITE_FUNC_T original_write = dlsym(RTLD_DEFAULT, "write");; > ssize_t corruption_write(int fd, const void *buf, size_t size) { > FBFatal(fd != trap_fd, @"Writing to the honeypot file"); > } > return original_write(fd, buf, size); > } > // Replace the system write with our “checked version” > rebind_…

> Does this code snippet look fishy to anyone else?

If you can still edit your post, try block-indenting the entire code list with four spaces along the left margin -- this allows the code to appear on separate lines as intended and preserves the original indentation.

Re: Debugging file corruption on iOS

#20

Post by nspiegelberg »

fdawg4l wrote: post #17

> // setup a honeypot file > int trap_fd = open(…); > // Create new function to detect writes to the honeypot > static WRITE_FUNC_T original_write = dlsym(RTLD_DEFAULT, "write");; > ssize_t corruption_write(int fd, const void *buf, size_t size) { > FBFatal(fd != trap_fd, @"Writing to the honeypot file"); > } > return original_write(fd, buf, size); > } > // Replace the system write with our “checked version” > rebind_…

1. I added an extra brace after FBFatal in a final revision :( I'll ask for a revision 2. FBFatal has the same semantics as assert(), so that's correct. 3. The 'rebind_symbols' line truncates and is missing a horizontal scroll. You can view the rest of it if you click drag.
Post reply on HN