Re: Calling fopen() from a simple C++ program in Xcode 5.0.2 raises EXC_BAD_ACCESS, code=2

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Calling fopen() from a simple C++ program in Xcode 5.0.2 raises EXC_BAD_ACCESS, code=2

Subject: Re: Calling fopen() from a simple C++ program in Xcode 5.0.2 raises EXC_BAD_ACCESS, code=2
From: Dan Korn <email@hidden>
Date: Tue, 31 Dec 2013 14:43:21 -0600

Thanks Jean-Daniel, using "curl" works great, at least in Mavericks! I was able to download the .dmg file in segments with curl, then "cat" it all back together again, and restore it to a partition.

Unfortunately, once I got my Mountain Lion partition restored on my new Mac, it wouldn't boot. After another fruitless (no pun intended) searching session about that, I went to the Apple Store, where they informed me that my brand-new MacBook Pro would not run Mountain Lion; the hardware is not compatible. Apparently the "late 2013" models which come with Mavericks pre-installed can't run any other versions of OS X. Ironically, I could have bought a MacBook Pro earlier in the year, and that would have run Mountain Lion just fine, but I waited to get the new version. Of course, I had no way of knowing that the new one wouldn't run what I needed it to, especially since, as far as I know, this is the first time that Apple has released hardware that won't run at least one previous version of the OS.

So, I guess I'm back to my two-year-old laptop, which can run everything from Snow Leopard through Mavericks.

Once again, I have to salute Apple for their relentless forward thinking, where everything works great, as long as you have the newest hardware, and the newest version of OS X, and are only building for the newest versions as well. (Why would you want to support customers using year-old machines?) Fortunately, this salute requires only one finger.

(By the way, while "curl" worked great under Mavericks on my new laptop, it didn't seem to work with the large file offsets under Snow Leopard on my old laptop. Presumably this is a 32-bit issue that's fixed in 64-bit.)

On Wed, Dec 25, 2013 at 4:32 AM, Jean-Daniel Dupas <email@hidden> wrote:

Depending how the server enforce limitation, you may managed to do what you want using curl and the '-r' option, which let you specify a range of the file you want to download.

Maybe requesting "small enough" ranges one after an other will work.

Le 24 déc. 2013 à 19:31, Dan Korn <email@hidden> a écrit :

Thanks Ken. That was it. That also explains why removing the code that declares that variable prevents the crash.

FWIW, the same program built and debugged in Visual Studio raises a stack overflow exception, which is much more helpful feedback than just "bad access."

I guess I failed at my little C++ 101 project here. (I'm also getting zero back from the call to fread; I need to put specify the item size of 1 before the size in bytes.)

By the way, what I'm really trying to do is download a very large .dmg file that was my setup from my old MacBook Pro, so that I can restore it to a partition on the new one. It's on a server which apparently has no limit on the size of files you can upload, but does have a limit on the size of a file you can download.

Thanks again,
Dan

On Mon, Dec 23, 2013 at 11:45 PM, Ken Thomases <email@hidden> wrote:

On Dec 23, 2013, at 9:49 PM, Dan Korn wrote:

  const size_t inBufferSize = 10000000; // about 10 MB

char buffer[inBufferSize];

The default stack size is 8MB. Your "buffer" variable exceeds that. I suspect that's the problem. Don't put such large buffers on the stack. Allocate them on the heap.

Regards,
Ken

On Mon, Dec 23, 2013 at 11:45 PM, Ken Thomases <email@hidden> wrote:

On Dec 23, 2013, at 9:49 PM, Dan Korn wrote:

  const size_t inBufferSize = 10000000; // about 10 MB

char buffer[inBufferSize];

The default stack size is 8MB. Your "buffer" variable exceeds that. I suspect that's the problem. Don't put such large buffers on the stack. Allocate them on the heap.

Regards,
Ken

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list      (email@hidden)

This email sent to email@hidden

-- Jean-Daniel

 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

Follow-Ups:
- Re: Calling fopen() from a simple C++ program in Xcode 5.0.2 raises EXC_BAD_ACCESS, code=2
  - From: "Clark S. Cox III" <email@hidden>
- Re: Calling fopen() from a simple C++ program in Xcode 5.0.2 raises EXC_BAD_ACCESS, code=2
  - From: Quincey Morris <email@hidden>
- Re: Calling fopen() from a simple C++ program in Xcode 5.0.2 raises EXC_BAD_ACCESS, code=2
  - From: Kyle Sluder <email@hidden>

References:
	>Calling fopen() from a simple C++ program in Xcode 5.0.2 raises EXC_BAD_ACCESS, code=2 (From: Dan Korn <email@hidden>)
	>Re: Calling fopen() from a simple C++ program in Xcode 5.0.2 raises EXC_BAD_ACCESS, code=2 (From: Ken Thomases <email@hidden>)
	>Re: Calling fopen() from a simple C++ program in Xcode 5.0.2 raises EXC_BAD_ACCESS, code=2 (From: Dan Korn <email@hidden>)
	>Re: Calling fopen() from a simple C++ program in Xcode 5.0.2 raises EXC_BAD_ACCESS, code=2 (From: Jean-Daniel Dupas <email@hidden>)

Prev by Date: Re: Have I any recourse?
Next by Date: Re: Have I any recourse?
Previous by thread: Re: Calling fopen() from a simple C++ program in Xcode 5.0.2 raises EXC_BAD_ACCESS, code=2
Next by thread: Re: Calling fopen() from a simple C++ program in Xcode 5.0.2 raises EXC_BAD_ACCESS, code=2
Index(es):
- Date
- Thread