From what I have read over the weekend, the launch pad processing of space shuttle discovery is still on track. Fuels have been loaded to the shuttle. They are used to power all sort of auxiliary systems. A countdown test with the crew on site is scheduled for mid this week. That countdown test seems also to be a chance to do the APU hotfire test, which still is considered.
NASA my skip APU hotfire test, crawler headed back…
Still, no official news from NASA. But from what I have gathered on several forums on the Internet, Discovery is still on schedule. A tight schedule – as said yesterday, there seems to be only a few hours of contingency left.
In spite of this, NASA considers to drop the so-called APU hotfire test. APUs provide power e.g. for hydraulics during re-entry. The APU test was originally scheduled for shortly after arrival at the pad. However, it could not be carried out due to bad weather. It is now targeted for next Thursday — if not being canceled. Canceling seems attractive to NASA, as it would probably save around one day of contingency. And the APU test is not considered absolutely vital – it is recommenced only after a major overhaul of the orbiter (which, however, seems to have happened).
As a side-note, the crawler transporter has now left the pad. Look at the picture above — not to long ago this was where the crawler parked. Driving back seems to be a bit quick, as it usually stays until shortly before launch. Maybe this is another indication that NASA is very serious on launching as quickly as possible.
Could I really reproduce the bug…?
Today, I was able to actually test and debug rsyslog Not just looking at code and how it may work. No, real interaction and real crashes.
Things went well, but then I got stuck. Somehow, the segfault didn’t make much sense. I found something that is related to the segfault user’s are seeing. But is it really the actual segfault or just a side-effect of instrumentation?
With mudflap active, rsyslog crashes when freeing the message structure in the worker thread. The structure was allocated (malloc) in another thread, actually the “main” thread, that is the one rsyslog starts up in. Of course, I’ve first assumed I have messed up with the structure. But further analysis showed that I have not. So a bad feeling creeped in … that there may be some thread safety issues with malloc/free. On the other hand, rsyslog is far from being my first multi-threaded program (but on a modern flavor of linux, I have to admit). I’ve used dynamic memory alloc in multithreaded apps for years now and without any problems. After all, dynamic memory is often a trouble-safer with multithreading.
Then, I have written a minimalistic program to check out threading functionality. Here it is:
#include <stdlib.h>
#include <pthread.h>
static char *pthrd;
static char *pmain;
static void *singleWorker1()
{
pthrd = malloc(32);
printf("alloc p in thread: %8.8xn", pthrd);
pthread_exit(0);
}
static void *singleWorker2()
{
printf("freeing p from thread: %8.8xn", pthrd);
free(pthrd);
printf("free done!n");
printf("freeing p from main thread: %8.8xn", pmain);
free(pmain);
printf("free done!n");
pthread_exit(0);
}
void main()
{
int i;
pthread_t thrdWorker;
i = pthread_create(&thrdWorker, NULL, singleWorker1, NULL);
pthread_join(thrdWorker, NULL);
pmain = malloc(32);
printf("alloc p in main thread: %8.8xn", pmain);
i = pthread_create(&thrdWorker, NULL, singleWorker2, NULL);
pthread_join(thrdWorker, NULL);
printf("main thread exitingn");
}
Note: the code did originally contain sleep(1) in stead of the pthread_join()s now found in it. I was initially too lazy to do it right in this tester. I’ve been told this is bad, so I fixed it. The result, however, is unchanged.
… and now look at the output:
cc -O1 -fmudflapth threadtest.c -lpthread -lmudflapth
threadtest.c: In function ‘main’:
threadtest.c:27: warning: return type of ‘main’ is not ‘int’
[root@localhost rsyslog]# ./a.out
malloc: using debugging hooks
alloc p in thread: 095586d0
alloc p in main thread: 095587f8
freeing p from thread: 095586d0
free done!
freeing p from main thread: 095587f8
*** glibc detected *** ./a.out: free(): invalid pointer: 0x095587f8 ***
free done!
main thread exiting
*******
mudflap stats:
calls to __mf_check: 0
__mf_register: 5179 [524294B, 32B, 20981024B, 0B, 2365B]
__mf_unregister: 0 [0B]
__mf_violation: [0, 0, 0, 0, 0]
calls with reentrancy: 5132
lock contention: 0
lookup cache slots used: 0 unused: 1024 peak-reuse: 0
number of live objects: 5179
zombie objects: 0
As you can see, the free that is done on the memory malloc’ed in the thread I created manually works fine. But the freeing the memory malloc’ed in the main thread fails miserably (I’ve set MALLOC_CHECK_=1, for the records).
I am both stunned and puzzled. If that is really a problem, it is clear why rsyslog aborts.
… but can that really be? I have to admit I now suspect a problem with mudflap — when it is compiled without it, everything works. But this applies only to the test program. Rsyslog doesn’t as quickly abort compiled without mudflap, but it aborts in any case. So can there really be a problem in the way dynamic memory management is done and in which threads?
If you can contribute to the solution, please do. I really need any helping hand, this is probably one of the most strange situations I’ve ever seen [and, of course, all will clear up once I see where I have failed – as always ;)].
Feedback appreciated!
finally … I can produce a segfault!
Thanks to mildew, I can now produce a rsyslog segfault. It even happens immediately at startup. Actually, it’s a bit quick, I’d expected it to occur much later. But it looks similar enough to the bug reports I received, so I can hunt that one down (yes, it seems to occur persistently)! Chances are pretty good that, if it is fixed, the real culprit is found.
Ah … and what was the magic? Mildew suggested to add mudflap to the project. I have to admit I was unaware of this capability. I guess, I’ll now make it a standard part of the debug environment – but let’s hunt the bug first…
homeland security can not secure its mailing list
This morning, I had in interesting find in my inbox. The department of homeland security seems not to be able (or not interested) to secure some of its public announcement lists. Read the original news here:
http://isc.sans.org/diary.html?storyid=3450
Of course, this is not a real thread – but I find it an interesting fact…
buffer time is being eaten up…
Still, few news from NASA. But some Internet forums have coverage. According to them, the contingency day that was left is shrinking. So there seem to be only some hours of contingency (buffer time) left. If that contingency is eaten up, the launch will be delayed. That, in turn, could pose problems for the next mission, STS-122, as the schedule is very tight.
In some forum it is already being speculated if NASA is skipping some tests to save time. I think the guys at NASA know well what they are doing. I also believe they are quite responsible people. So, at least I hope, if they skip a test it is safe to do so.
Anyhow, it’ll be interesting to see if the launch date slips — and how this affects my travel schedule.
Oh, yes: sorry, folks, so far no new interesting pictures. If find some, I’ll post as soon as I do…
Astronauts ride rollercoasters – really…
OK, I have to admit this is totally off-topic for the time being. But as I said: this blog is probably not only about the space shuttle, but space launches (and me viewing them ;)) in general. As such, I’d like to stuff in some notes on the Ares rockets right now (after 2012 it’s probably more interesting, but anyhow…).
When I visited the NASA home page to pick up news about Discovery, I was dragged in by a page about the ares rockets and, more precisely, the escape system that astronauts use when things go wrong. Of course, all of this is just a model, not real hardware. That escape system is based on a roller coaster. Just read what NASA says:
As NASA revamps Launch Complex 39B to host the new Orion spacecraft and Ares I rocket of the Constellation Program, engineers are preparing to install a new kind of departure system to evacuate astronauts.
The agency calls it the Orion Emergency Egress System, but it is fundamentally a group of multi-passenger cars on a set of rails reminiscent of a roller coaster. Its purpose is to move astronauts and ground crew quickly from the vehicle entry on the launch pad to a protective concrete bunker in case of an emergency.
The emergency egress system for Ares will carry astronauts and ground crew.
Similar systems have been built into launch pads since the Saturn rockets and for the space shuttle. Both earlier systems were cables running from the spacecraft’s crew ingress level to an area near a bunker. There has never been an emergency on the pad that required the crew use these systems.
For Orion, the rail car would stand some 380 feet above the ground. It will be at the same height as the hatch on the Orion capsule, which is where the astronaut crews enter the spacecraft before launch.
Kelli Maloney, the lead designer for the launch pad escape system, said a trade study showed the railcar best met NASA’s requirements. Those requirements call for astronauts to be able to get out of the spacecraft and into the bunker within 4 minutes.
One of the benefits of the rail system, Maloney said, is that the track can take the astronauts directly to the bunker door. That would be a big help if one of the crew members or a ground crew member was incapacitated.
Scott Colloredo, NASA’s senior project integrator for Constellation ground systems, said the group called on the world’s roller coaster designers for help with the concept.
“It’s obviously not a thrill ride, but we’re taking advantage of technology that’s there,” he said.
I just hope that rollercoaster is never to be used in practice…
Source: http://www.nasa.gov/mission_pages/constellation/main/railcarevac.html
oops … crawler is parked
I think I was a bit to fast with my assumption that the crawler transporter is heading back from the launch pad. I have re-checked the cams and it has not moved an further. So I assume we see it in its parking position. That seems to be normal – the crawler transporter seem to typically stay a while at the pad after the space shuttle has been delivered.
I have also dug out an up-close picture of a crawler that I made on my last visit of Kennedy Space Center in September 2006. Look at the left – there you can see one of its driver’s cabin. Think that people are in there, then think about how big it is ;)
crawler transporter heading back
I was on the search for some image footage of space shuttle Discovery at the launch pad (now with the payload integrated). In one of the NASA webcams I came across this nice picture. It shows the crawler transporter heading back from the pad. As the webcams are usually live, it looks like the crawler has parked at the pad.
finally: new news ;)
Finally, NASA has released some news item. On the space shuttle home page, they state:
On Launch Pad 39A at NASA’s Kennedy Space Center in Florida, the payload for mission STS-120 has been installed in space station Discovery’s cargo bay. The payload includes the Italian-built U.S. Harmony module, which will be delivered to the International Space Station during the mission. The module will serve as the future connecting point between the U.S. Destiny lab, the European Space Agency’s Columbus module and the Japanese Kibo module.
Hearing that is a relief for me. Since Sunday, there was no real news available. Of course, some forums had this and that note, but nothing official at all from the progress at Kennedy Space Center. Now, we know things look good.
Please note that there is not a single word about a schedule slip, so we seem to be still on time.