Boost logo

Boost Testing :

Subject: Re: [Boost-testing] bjam.exe crashed, took other apps down with it
From: Christoph Macheiner (Christoph.Macheiner_at_[hidden])
Date: 2014-04-02 13:30:01

This is one of two incarnations of the infamous IN_PAGE_ERROR. If you run an application (or use dlls) from a network share (so your F: drive must one, and not a local disk), and the network is unavailable when the code that is to be executed is currently not in memory (and so needs to be paged in from the dll/exe sitting on the network share) you crash with C0000006 or C00000fd. The chances of this happening are quite high, because for reasons unknown, the memory manager is incredibly aggressive when paging out memory pages that are mapped to code segments, and the retry period is very short. In such a case, even a fraction of a millisecond of network outage will bring you down.

There is an image flag that causes the loader to preload the binaries into the swap file and then run it from there, thus eliminating this issue. This flag is read from the .exe and is effective for all binaries loaded into that process. You can set it like so:

editbin.exe /SWAPRUN:NET bjam.exe

The editbin.exe is in VC\bin in your VS installation. There is also a corresponding "/SWAPRUN:NET" linker switch if you want to build bjam that way in the first place.

If an executable does not have this flag set, and uses binaries from a network share (or is itself run from a share), it is otherwise impossible to guarantee that such a crash does not happen. Personally, I have always advised against running from a network share.

It is close to impossible that the other crashes are caused by bjam (but of course might be caused by a network issue), but for that I would at least need to see the corresponding event log entries.

Best regards, Christoph.

update software AG
Operngasse 17-21 | 1040 Vienna | Austria
Christoph.Macheiner_at_[hidden] |
> Our customers are more successful.

This email and attachments are intended for the above name only and are confidential.
If you are not the intended addressee, or the person responsible for delivering it to the
intended addressee, you may neither copy nor deliver it to anyone else or use it in any
unauthorized manner. To do so is prohibited and may be unlawful. If you receive this
email by mistake, please advise the sender immediately by using the reply facility in
your email software.
Unless instructed by you, we will retain your personal details in our international data-
base for future business-related purposes.
This message has been checked for the presence of computer viruses. For further
information on our company,please visit our website at
update software AG - Aktiengesellschaft
Firmenbuch Wien FN 113675w
Sitz der Gesellschaft: Wien
Gesch?ftsleitung: Thomas Deutschmann (Vorstandsvorsitzender), Arno Huber (Vorstand),
Uwe Reumuth (Vorstand), Frank Hurtmanns (Aufsichtsratsvorsitzender),
Richard Roy, Hans Strack Zimmermann, Josef Blazicek, Gerhard Auer, Helmut Fink (Aufsichtsr?te)
UID Nr.: ATU15128500
-------------------------------------------------------------------------------Disclaimer-----------Original Message-----
From: Boost-Testing [mailto:boost-testing-bounces_at_[hidden]] On Behalf Of Jim Bell
Sent: Mittwoch, 02. April 2014 18:19
To: Running Boost regression tests
Subject: [Boost-testing] bjam.exe crashed, took other apps down with it

bjam.exe just crashed while running a regression, and as I've seen happen before, it seemed to take down some number of other applications with it. The ones I saw go down were: Google Chrome browser
(33.0.1750.154 m, marked up-to-date), and "Sticky Notes" (windows accessory app). Don't know how many other (background) apps went down as well. (My hunch is that the other apps that crashed are tied together by the 32-bit kernel32.dll.)

It was running the regression for MinGW-w64-4.7, --tag=develop.

Windows 7 Ultimate SP1 x64, 16GB RAM.

Wasn't monitoring RAM when it happened, so I don't know if something squirrly happened in that domain. But didn't see any other symptoms.

This bjam.exe was built from --tag=develop on 3/28. (I doubt recent bjam changes had anything to do with it.) Nothing happened on stdout (and carried on, firing process_jam_log).

See also:

The Windows Event Log says:
Faulting application name: bjam.exe, version:, time stamp:
Faulting module name: kernel32.dll, version: 6.1.7601.18229, time stamp:
Exception code: 0xc00000fd
Fault offset: 0x00038b75
Faulting process id: 0x1294
Faulting application start time: 0x01cf4e5b4b11f5d1 Faulting application path: F:\boost\gcc\develop\bjam.exe Faulting module path: C:\Windows\syswow64\kernel32.dll Report Id: f48e05b8-ba7c-11e3-bac1-005056c00008


Boost-testing list run by mbergal at