text:
Runtime checking (RTC) lets you automatically detect runtime errors, such as memory access errors and memory leak, in a native code application during the development phase. It also lets you monitor memory usage. You cannot use runtime checking on Java code.
The following topics are covered in this chapter:
Runtime checking is available on platforms running the Solaris OS only. It is not available on platforms running the Linux OS.
Because runtime checking is an integral debugging feature, you can perform all debugging operations while using runtime checking except collecting performance data using the Collector.
Runtime checking:
Detects memory access errors
Detects memory leaks
Collects data on memory use
Works with all languages
Works with multithreaded code
Requires no recompiling, relinking, or makefile changes
Compiling with the -g flag provides source line number correlation in the runtime checking error messages. Runtime checking can also check programs compiled with the optimization -O flag. There are some special considerations with programs not compiled with the -g option.
You can use runtime checking by using the check command.
One way to avoid seeing a large number of errors at once is to use runtime checking earlier in the development cycle—as you are developing the individual modules that make up your program. Write a unit test to drive each module and use runtime checking incrementally to check one module at a time. That way, you deal with a smaller number of errors at a time. When you integrate all of the modules into the full program, you are likely to encounter few new errors. When you reduce the number of errors to zero, you need to run runtime checking again only when you make changes to a module.
To use runtime checking, you must fulfill the following requirements:
Programs compiled using a Sun compiler.
Dynamic linking with libc.
Use of the standard libc malloc, free, and realloc functions or allocators based on those functions. Runtime checking provides an application programming interface (API) to handle other allocators. See Runtime Checking Application Programming Interface.
Programs that are not fully stripped; programs stripped with strip -x are acceptable.
For information on the limitations of runtime checking, see Runtime Checking Limitations.
To use runtime checking, enable the type of checking you want to use before you run the program.
To turn on memory use and memory leak checking, type:
(dbx) check -memuse
When memory use checking or memory leak checking is turned on, the showblock command shows the details about the heap block at a given address. The details include the location of the block's allocation and its size. For more information, see showblock Command.
To turn on memory access checking only, type:
(dbx) check -access
To turn on memory leak, memory use, and memory access checking, type:
(dbx) check -all
For more information, see check Command.
To turn off runtime checking entirely, type:
(dbx) uncheck -all
For detailed information, see uncheck Command.
After turning on the types of runtime checking you want, run the program being tested, with or without breakpoints.
The program runs normally, but slowly because each memory access is checked for validity just before it occurs. If dbx detects invalid access, it displays the type and location of the error. Control returns to you (unless the dbx environment variable rtc_auto_continue is set to on (see Setting dbx Environment Variables.)
You can then issue dbx commands, such as where to get the current stack trace or print to examine variables. If the error is not a fatal error, you can continue execution of the program with the cont command. The program continues to the next error or breakpoint, whichever is detected first. For detailed information, see cont Command.
If the rtc_auto_continue environment variable is set to on, runtime checking continues to find errors, and keeps running automatically. It redirects errors to the file named by the dbx environment variable rtc_error_log_file_name. (See Setting dbx Environment Variables.) The default log file name is /tmp/dbx.errlog.uniqueid.
You can limit the reporting of runtime checking errors using the suppress command. For detailed information, see suppress Command.
Below is a simple example showing how to turn on memory access and memory use checking for a program called hello.c.
% cat -n hello.c 1 #include <stdio.h> 2 #include <stdlib.h> 3 #include <string.h> 4 5 char *hello1, *hello2; 6 7 void 8 memory_use() 9 { 10 hello1 = (char *)malloc(32); 11 strcpy(hello1, "hello world"); 12 hello2 = (char *)malloc(strlen(hello1)+1); 13 strcpy(hello2, hello1); 14 } 15 16 void 17 memory_leak() 18 { 19 char *local; 20 local = (char *)malloc(32); 21 strcpy(local, "hello world"); 22 } 23 24 void 25 access_error() 26 { 27 int i,j; 28 29 i = j; 30 } 31 32 int 33 main() 34 { 35 memory_use(); 36 access_error(); 37 memory_leak(); 38 printf("%s\n", hello2); 39 return 0; 40 } % cc -g -o hello hello.c % dbx -C hello Reading ld.so.1 Reading librtc.so Reading libc.so.1 Reading libdl.so.1 (dbx) check -access access checking - ON (dbx) check -memuse memuse checking - ON (dbx) run Running: hello (process id 18306) Enabling Error Checking... done Read from uninitialized (rui): Attempting to read 4 bytes at address 0xeffff068 which is 96 bytes above the current stack pointer Variable is 'j' Current function is access_error 29 i = j; (dbx) cont hello world Checking for memory leaks... Actual leaks report (actual leaks: 1 total size: 32 bytes) Total Num of Leaked Allocation call stack Size Blocks Block Address ========== ====== ========== ======================================= 32 1 0x21aa8 memory_leak < main Possible leaks report (possible leaks: 0 total size: 0 bytes) Checking for memory use... Blocks in use report (blocks in use: 2 total size: 44 bytes Total % of Num of Avg Allocation call stack Size All Blocks Size ========== ==== ====== ====== ======================================= 32 72% 1 32 memory_use < main 12 27% 1 12 memory_use < main execution completed, exit code is 0
The function access_error() reads variable j before it is initialized. Runtime checking reports this access error as a Read from uninitialized (rui).
The function memory_leak() does not free the variable local before it returns. When memory_leak() returns, this variable goes out of scope and the block allocated at line 20 becomes a leak.
The program uses global variables hello1 and hello2, which are in scope all the time. They both point to dynamically allocated memory, which is reported as Blocks in use (biu).
Access checking checks whether your program accesses memory correctly by monitoring each read, write, allocate, and free operation.
Programs might incorrectly read or write memory in a variety of ways; these are called memory access errors. For example, the program may reference a block of memory that has been deallocated through a free()call for a heap block. Or a function might return a pointer to a local variable, and when that pointer is accessed an error would result. Access errors might result in wild pointers in the program and can cause incorrect program behavior, including wrong outputs and segmentation violations. Some kinds of memory access errors can be very hard to track down.
Runtime checking maintains a table that tracks the state of each block of memory being used by the program. Runtime checking checks each memory operation against the state of the block of memory it involves and then determines whether the operation is valid. The possible memory states are:
Unallocated, initial state. Memory has not been allocated. It is illegal to read, write, or free this memory because it is not owned by the program.
Allocated, but uninitialized. Memory has been allocated to the program but not initialized. It is legal to write to or free this memory, but is illegal to read it because it is uninitialized. For example, upon entering a function, stack memory for local variables is allocated, but uninitialized.
Read-only. It is legal to read, but not write or free, read-only memory.
Allocated and initialized. It is legal to read, write, or free allocated and initialized memory.
Using runtime checking to find memory access errors is not unlike using a compiler to find syntax errors in your program. In both cases, a list of errors is produced, with each error message giving the cause of the error and the location in the program where the error occurred. In both cases, you should fix the errors in your program starting at the top of the error list and working your way down. One error can cause other errors in a chain reaction. The first error in the chain is, therefore, the "first cause," and fixing that error might also fix some subsequent errors.
For example, a read from an uninitialized section of memory can create an incorrect pointer, which when dereferenced can cause another invalid read or write, which can in turn lead to yet another error.
Runtime checking prints the following information for memory access errors:
Type of error.
Type of access attempted (read or write).
Size of attempted access.
Address of attempted access.
Size of leaked block.
More detailed information about address. For example, if the address is in the vicinity of the stack, then its position relative to the current stack pointer is given. If the address is in the heap, then the address, size, and relative position of the nearest heap block is given.
Call stack at time of error (with batch mode).
If the address is in the heap, then the allocation trace of the nearest heap block is given.
Where the error occurred. If line number information is available, this information includes line number and function. If line numbers are not available, runtime checking provides function and address.
The following example shows a typical access error.
Read from uninitialized (rui): Attempting to read 4 bytes at address 0xefffee50 which is 96 bytes above the current stack pointer Variable is "j' Current function is rui 12 i = j;
Runtime checking detects the following memory access errors:
rua (see Read From Unallocated Memory (rua) Error)
wua (see Write to Unallocated Memory (wua) Error)
wro (see Write to Read-Only Memory (wro) Error)
mar (see Misaligned Read (mar) Error)
maw (see Misaligned Write (maw) Error)
duf (see Duplicate Free (duf) Error)
baf (see Bad Free (baf) Error)
maf (see Misaligned Free (maf) Error)
oom (see Out of Memory (oom) Error)
Runtime checking does not perform array bounds checking and, therefore, does not report array bound violations as access errors.
A memory leak is a dynamically allocated block of memory that has no pointers pointing to it anywhere in the data space of the program. Such blocks are orphaned memory. Because there are no pointers pointing to the blocks, programs cannot reference them, much less free them. Runtime checking finds and reports such blocks.
Memory leaks result in increased virtual memory consumption and generally result in memory fragmentation. This might slow down the performance of your program and the whole system.
Typically, memory leaks occur because allocated memory is not freed and you lose a pointer to the allocated block. Here are some examples of memory leaks:
void foo() { char *s; s = (char *) malloc(32); strcpy(s, "hello world"); return; /* no free of s. Once foo returns, there is no */ /* pointer pointing to the malloc'ed block, */ /* so that block is leaked. */ }
A leak can result from incorrect use of an API.
void printcwd() { printf("cwd = %s\n", getcwd(NULL, MAXPATHLEN)); return; /* libc function getcwd() returns a pointer to */ /* malloc'ed area when the first argument is NULL, */ /* program should remember to free this. In this */ /* case the block is not freed and results in leak.*/ }
You can avoid memory leaks by always freeing memory when it is no longer needed and paying close attention to library functions that return allocated memory. If you use such functions, remember to free up the memory appropriately.
Sometimes the term memory leak is used to refer to any block that has not been freed. This is a much less useful definition of a memory leak, because it is a common programming practice not to free memory if the program will terminate shortly. Runtime checking does not report a block as a leak, if the program still retains one or more pointers to it.
Runtime checking detects the following memory leak errors:
mel (see Memory Leak (mel) Error)
air (see Address in Register (air) Error)
aib (see Address in Block (aib) Error)
Runtime checking only finds leaks of malloc memory. If your program does not use malloc, runtime checking cannot find memory leaks.
There are two cases where runtime checking can report a "possible" leak. The first case is when no pointers are found pointing to the beginning of the block, but a pointer is found pointing to the interior of the block. This case is reported as an "Address in Block (aib)" error. If it was a stray pointer that pointed into the block, this would be a real memory leak. However, some programs deliberately move the only pointer to an array back and forth as needed to access its entries. In this case, it would not be a memory leak. Because runtime checking cannot distinguish between these two cases, it reports both of them as possible leaks, letting you determine which are real memory leaks.
The second type of possible leak occurs when no pointers to a block are found in the data space, but a pointer is found in a register. This case is reported as an "Address in Register (air)" error. If the register points to the block accidentally, or if it is an old copy of a memory pointer that has since been lost, then this is a real leak. However, the compiler can optimize references and place the only pointer to a block in a register without ever writing the pointer to memory. Such a case would not be a real leak. Hence, if the program has been optimized and the report was the result of the showleaks command, it is likely not to be a real leak. In all other cases, it is likely to be a real leak. For more information, see showleaks Command.
Runtime leak checking requires the use of the standard libc malloc/free/realloc functions or allocators based on those functions. For other allocators, see Runtime Checking Application Programming Interface .
If memory leak checking is turned on, a scan for memory leaks is automatically performed just before the program being tested exits. Any detected leaks are reported. The program should not be killed with the kill command. Here is a typical memory leak error message:
Memory leak (mel): Found leaked block of size 6 at address 0x21718 At time of allocation, the call stack was: [1] foo() at line 63 in test.c [2] main() at line 47 in test.c
A UNIX program has a main procedure (called MAIN in f77) that is the top-level user function for the program. Normally, a program terminates either by calling exit(3) or by returning from main. In the latter case, all variables local to main go out of scope after the return, and any heap blocks they pointed to are reported as leaks (unless global variables point to those same blocks).
It is a common programming practice not to free heap blocks allocated to local variables in main, because the program is about to terminate and return from main without calling exit(). To prevent runtime checking from reporting such blocks as memory leaks, stop the program just before main returns by setting a breakpoint on the last executable source line in main. When the program halts there, use the showleaks command to report all the true leaks, omitting the leaks that would result merely from variables in main going out of scope.
For more information, see showleaks Command.
With leak checking turned on, you receive an automatic leak report when the program exits. All possible leaks are reported—provided the program has not been killed using the kill command. The level of detail in the report is controlled by the dbx environment variable rtc_mel_at_exit (see Setting dbx Environment Variables). By default, a nonverbose leak report is generated.
Reports are sorted according to the combined size of the leaks. Actual memory leaks are reported first, followed by possible leaks. The verbose report contains detailed stack trace information, including line numbers and source files whenever they are available.
Both reports include the following information for memory leak errors:
Size of leaked block.
Location where leaked block was allocated.
Address of leaked block.
Call stack at time of allocation, as constrained by check -frames.
Here is the corresponding nonverbose memory leak report.
Actual leaks report (actual leaks: 3 total size: 2427 bytes) Total Num of Leaked Allocation call stack Size Blocks Block Address ========== ====== ========== ======================================= 1852 2 - true_leak < true_leak 575 1 0x22150 true_leak < main Possible leaks report (possible leaks: 1 total size: 8 bytes) Total Num of Leaked Allocation call stack Size Blocks Block Address ========== ====== ========== ======================================= 8 1 0x219b0 in_block < main
Following is a typical verbose leak report.
Actual leaks report (actual leaks: 3 total size: 2427 bytes) Memory Leak (mel): Found 2 leaked blocks with total size 1852 bytes At time of each allocation, the call stack was: [1] true_leak() at line 220 in "leaks.c" [2] true_leak() at line 224 in "leaks.c" Memory Leak (mel): Found leaked block of size 575 bytes at address 0x22150 At time of allocation, the call stack was: [1] true_leak() at line 220 in "leaks.c" [2] main() at line 87 in "leaks.c" Possible leaks report (possible leaks: 1 total size: 8 bytes) Possible memory leak -- address in block (aib): Found leaked block of size 8 bytes at address 0x219b0 At time of allocation, the call stack was: [1] in_block() at line 177 in "leaks.c" [2] main() at line 100 in "leaks.c"
You can ask for a leak report at any time using the showleaks command, which reports new memory leaks since the last showleaks command. For more information, see showleaks Command.
Because the number of individual leaks can be very large, runtime checking automatically combines leaks allocated at the same place into a single combined leak report. The decision to combine leaks, or report them individually, is controlled by the number-of-frames-to-match parameter specified by the -match m option on a check -leaks or the -m option of the showleaks command. If the call stack at the time of allocation for two or more leaks matches to m frames to the exact program counter level, these leaks are reported in a single combined leak report.
Consider the following three call sequences:
Block 1
Block 2
Block 3
[1] malloc
[1] malloc
[1] malloc
[2] d() at 0x20000
[2] d() at 0x20000
[2] d() at 0x20000
[3] c() at 0x30000
[3] c() at 0x30000
[3] c() at 0x31000
[4] b() at 0x40000
[4] b() at 0x41000
[4] b() at 0x40000
[5] a() at 0x50000
[5] a() at 0x50000
[5] a() at 0x50000
If all of these blocks lead to memory leaks, the value of m determines whether the leaks are reported as separate leaks or as one repeated leak. If m is 2, Blocks 1 and 2 are reported as one repeated leak because the 2 stack frames above malloc() are common to both call sequences. Block 3 will be reported as a separate leak because the trace for c() does not match the other blocks. For m greater than 2, runtime checking reports all leaks as separate leaks. (The malloc is not shown on the leak report.)
In general, the smaller the value of m, the fewer individual leak reports and the more combined leak reports are generated. The greater the value of m, the fewer combined leak reports and the more individual leak reports are generated.
Once you have obtained a memory leak report, follow these guidelines for fixing the memory leaks.
Most importantly, determine where the leak is. The leak report tells you the allocation trace of the leaked block, the place where the leaked block was allocated.
You can then look at the execution flow of your program and see how the block was used. If it is obvious where the pointer was lost, the job is easy; otherwise you can use showleaks to narrow your leak window. By default the showleaks command gives you the new leaks created only since the last showleaks command. You can run showleaks repeatedly while stepping through your program to narrow the window where the block was leaked.
For more information, see showleaks Command.
Memory use checking lets you see all the heap memory in use. You can use this information to get a sense of where memory is allocated in your program or which program sections are using the most dynamic memory. This information can also be useful in reducing the dynamic memory consumption of your program and might help in performance tuning
Memory use checking is useful during performance tuning or to control virtual memory use. When the program exits, a memory use report can be generated. Memory usage information can also be obtained at any time during program execution with the showmemuse command, which causes memory usage to be displayed. For information, see showmemuse Command.
Turning on memory use checking also turns on leak checking. In addition to a leak report at the program exit, you also get a blocks in use (biu) report. By default, a nonverbose blocks in use report is generated at program exit. The level of detail in the memory use report is controlled by the dbx environment variable rtc_biu_at_exit (see Setting dbx Environment Variables).
The following is a typical nonverbose memory use report.
Blocks in use report (blocks in use: 5 total size: 40 bytes) Total % of Num of Avg Allocation call stack Size All Blocks Size ========== ==== ====== ====== ===================================== 16 40% 2 8 nonleak < nonleak 8 20% 1 8 nonleak < main 8 20% 1 8 cyclic_leaks < main 8 20% 1 8 cyclic_leaks < main
Blocks in use report (blocks in use: 5 total size: 40 bytes) Block in use (biu): Found 2 blocks totaling 16 bytes (40.00% of total; avg block size 8) At time of each allocation, the call stack was: [1] nonleak() at line 182 in "memuse.c" [2] nonleak() at line 185 in "memuse.c" Block in use (biu): Found block of size 8 bytes at address 0x21898 (20.00% of total) At time of allocation, the call stack was: [1] nonleak() at line 182 in "memuse.c" [2] main() at line 74 in "memuse.c" Block in use (biu): Found block of size 8 bytes at address 0x21958 (20.00% of total) At time of allocation, the call stack was: [1] cyclic_leaks() at line 154 in "memuse.c" [2] main() at line 118 in "memuse.c" Block in use (biu): Found block of size 8 bytes at address 0x21978 (20.00% of total) At time of allocation, the call stack was: [1] cyclic_leaks() at line 155 in "memuse.c" [2] main() at line 118 in "memuse.c" The following is the corresponding verbose memory use report:
You can ask for a memory use report any time with the showmemuse command.
Runtime checking provides a powerful error suppression facility that allows great flexibility in limiting the number and types of errors reported. If an error occurs that you have suppressed, then no report is given, and the program continues as if no error had occurred.
You can suppress errors using the suppress command (see suppress Command).
You can undo error suppression using the unsuppress command (see unsuppress Command).
Suppression is persistent across run commands within the same debug session, but not across debug commands.
The following types of suppression are available:
You must specify which type of error to suppress. You can specify which parts of the program to suppress. The options are:
The default; applies to the whole program.
Load Object
Applies to an entire load object, such as a shared library, or the main program.
Applies to all functions in a particular file.
Applies to a particular function.
Applies to a particular source line.
Applies to a particular instruction at an address.
By default, runtime checking suppresses the most recent error to prevent repeated reports of the same error. This is controlled by the dbx environment variable rtc_auto_suppress. When rtc_auto_suppress is set to on (the default), a particular access error at a particular location is reported only the first time it is encountered and suppressed thereafter. This is useful, for example, for preventing multiple copies of the same error report when an error occurs in a loop that is executed many times.
You can use the dbx environment variable rtc_error_limit to limit the number of errors that will be reported. The error limit is used separately for access errors and leak errors. For example, if the error limit is set to 5, then a maximum of five access errors and five memory leaks are shown in both the leak report at the end of the run and for each showleaks command you issue. The default is 1000.
In the following examples, main.cc is a file name, foo and bar are functions, and a.out is the name of an executable.
Do not report memory leaks whose allocation occurs in function foo.
suppress mel in foo
Suppress reporting blocks in use allocated from libc.so.1.
suppress biu in libc.so.1
Suppress read from uninitialized in all functions in a.out.
suppress rui in a.out
Do not report read from unallocated in file main.cc.
suppress rua in main.cc
Suppress duplicate free at line 10 of main.cc.
suppress duf at main.cc:10
Suppress reporting of all errors in function bar.
suppress all in bar
For more information, see suppress Command.
To detect all errors, runtime checking does not require the program be compiled using the- g option (symbolic). However, symbolic information is sometimes needed to guarantee the correctness of certain errors, mostly rui errors. For this reason certain errors, rui for a.out and rui, aib, and air for shared libraries, are suppressed by default if no symbolic information is available. This behavior can be changed using the -d option of the suppress command and unsuppress command.
The following command causes runtime checking to no longer suppress read from uninitialized memory (rui) in code that does not have symbolic information (compiled without -g):
unsuppress -d rui
For more information, see unsuppress Command.
For the initial run on a large program, the large number of errors might be overwhelming. It might be better to take a phased approach. You can do so using the suppress command to reduce the reported errors to a manageable number, fixing just those errors, and repeating the cycle; suppressing fewer and fewer errors with each iteration.
For example, you could focus on a few error types at one time. The most common error types typically encountered are rui, rua, and wua, usually in that order. rui errors are less serious (although they can cause more serious errors to happen later). Often a program might still work correctly with these errors. rua and wua errors are more serious because they are accesses to or from invalid memory addresses and always indicate a coding error.
You can start by suppressing rui and rua errors. After fixing all the wua errors that occur, run the program again, this time suppressing only rui errors. After fixing all the rua errors that occur, run the program again, this time with no errors suppressed. Fix all the rui errors. Lastly, run the program a final time to ensure no errors are left.
If you want to suppress the last reported error, use suppress -last.
To use runtime checking on a child process, you must have the dbx environment variable rtc_inherit set to on. By default, it is set to off. (See Setting dbx Environment Variables.)
dbx supports runtime checking of a child process if runtime checking is enabled for the parent and the dbx environment variable follow_fork_mode is set to child (see Setting dbx Environment Variables).
When a fork happens, dbx automatically performs runtime checking on the child. If the program calls exec(), the runtime checking settings of the program calling exec() are passed on to the program.
At any given time, only one process can be under runtime checking control. The following is an example.
% cat -n program1.c 1 #include <sys/types.h> 2 #include <unistd.h> 3 #include <stdio.h> 4 5 int 6 main() 7 { 8 pid_t child_pid; 9 int parent_i, parent_j; 10 11 parent_i = parent_j; 12 13 child_pid = fork(); 14 15 if (child_pid == -1) { 16 printf("parent: Fork failed\n"); 17 return 1; 18 } else if (child_pid == 0) { 19 int child_i, child_j; 20 21 printf("child: In child\n"); 22 child_i = child_j; 23 if (execl("./program2", NULL) == -1) { 24 printf("child: exec of program2 failed\n"); 25 exit(1); 26 } 27 } else { 28 printf("parent: child's pid = %d\n", child_pid); 29 } 30 return 0; 31 }
% cat -n program2.c 1 2 #include <stdio.h> 3 4 main() 5 { 6 int program2_i, program2_j; 7 8 printf ("program2: pid = %d\n", getpid()); 9 program2_i = program2_j; 10 11 malloc(8); 12 13 return 0; 14 } %
% cc -g -o program1 program1.c % cc -g -o program2 program2.c % dbx -C program1 Reading symbolic information for program1 Reading symbolic information for rtld /usr/lib/ld.so.1 Reading symbolic information for librtc.so Reading symbolic information for libc.so.1 Reading symbolic information for libdl.so.1 Reading symbolic information for libc_psr.so.1 (dbx) check -all access checking - ON memuse checking - ON (dbx) dbxenv follow_fork_mode child (dbx) run Running: program1 (process id 3885) Enabling Error Checking... done RTC reports first error in the parent, program1 Read from uninitialized (rui): Attempting to read 4 bytes at address 0xeffff110 which is 104 bytes above the current stack pointer Variable is 'parent_j' Current function is main 11 parent_i = parent_j; (dbx) cont dbx: warning: Fork occurred; error checking disabled in parent detaching from process 3885 Attached to process 3886 Because follow_fork_mode is set to child, when the fork occurs error checking is switched from the parent to the child process stopped in _fork at 0xef6b6040 0xef6b6040: _fork+0x0008: bgeu _fork+0x30 Current function is main 13 child_pid = fork(); parent: child's pid = 3886 (dbx) cont child: In child Read from uninitialized (rui): Attempting to read 4 bytes at address 0xeffff108 which is 96 bytes above the current stack pointer RTC reports an error in the child Variable is 'child_j' Current function is main 22 child_i = child_j; (dbx) cont dbx: process 3886 about to exec("./program2") dbx: program "./program2" just exec'ed dbx: to go back to the original program use "debug $oprog" Reading symbolic information for program2 Skipping ld.so.1, already read Skipping librtc.so, already read Skipping libc.so.1, already read Skipping libdl.so.1, already read Skipping libc_psr.so.1, already read When the exec of program2 occurs, the RTC settings are inherited by program2 so access and memory use checking are enabled for that process Enabling Error Checking... done stopped in main at line 8 in file "program2.c" 8 printf ("program2: pid = %d\n", getpid()); (dbx) cont program2: pid = 3886 Read from uninitialized (rui): Attempting to read 4 bytes at address 0xeffff13c which is 100 bytes above the current stack pointer RTC reports an access error in the executed program, program2 Variable is 'program2_j' Current function is main 9 program2_i = program2_j; (dbx) cont Checking for memory leaks... RTC prints a memory use and memory leak report for the process that exited while under RTC control, program2 Actual leaks report (actual leaks: 1 total size: 8 bytes) Total Num of Leaked Allocation call stack Size Blocks Block Address ========== ====== ========== ==================================== 8 1 0x20c50 main Possible leaks report (possible leaks: 0 total size: 0 bytes) execution completed, exit code is 0
Runtime checking works on an attached process with the exception that RUI cannot be detected if the affected memory has already been allocated. However, the process must have rtcaudit.so preloaded when it starts. If the process to which you are attaching is a 64-bit process, use the appropriate 64-bit rtcaudit.so. If the product is installed in the /opt directory,rtcaudit.so is at:
/opt/SUNWspro/lib/v9/rtcaudit.so (for 64-bit SPARC platforms)
/opt/SUNWspro/lib/amd64/rtcaudit.so (for AMD64 platforms)
/opt/SUNWspro/lib for 32-bit platforms
% setenv LD_AUDIT path-to-rtcaudit/rtcaudit.so
Set the LD_AUDIT environment variableto preload rtcaudit.so only when needed; do not keep it loaded all the time. For example:
% setenv LD_AUDIT... % start-your-application % unsetenv LD_AUDIT
Once you attach to the process, you can enable runtime checking.
If the program you want to attach to is forked or executed from some other program, you need to set LD_AUDIT for the main program (which will fork). The setting of LD_AUDIT is inherited across forks and execution.
The LC_AUDITenvironment variable applies to both 32-bit programs and 64-bit programs, which makes it difficult to select the correct library for a 32-bit program that runs a 64-bit program, or a 64-bit program that runs a 32-bit program. Some versions of the Solaris OS support the LD_AUDIT_32 environment variable and the LD_AUDIT_64 environment variable, which affect only 32-bit programs and 64-bit programs, respectively. See the Linker and Libraries Guide for the version of the Solaris OS you are running to determine if these variables are supported.
You can use runtime checking along with fix and continue to isolate and fix programming errors rapidly. Fix and continue provides a powerful combination that can save you a lot of debugging time. Here is an example:.
% cat -n bug.c 1 #include stdio.h 2 char *s = NULL; 3 4 void 5 problem() 6 { 7 *s = 'c'; 8 } 9 10 main() 11 { 12 problem(); 13 return 0; 14 } % cat -n bug-fixed.c 1 #include stdio.h 2 char *s = NULL; 3 4 void 5 problem() 6 { 7 8 s = (char *)malloc(1); 9 *s = 'c'; 10 } 11 12 main() 13 { 14 problem(); 15 return 0; 16 } yourmachine46: cc -g bug.c yourmachine47: dbx -C a.out Reading symbolic information for a.out Reading symbolic information for rtld /usr/lib/ld.so.1 Reading symbolic information for librtc.so Reading symbolic information for libc.so.1 Reading symbolic information for libintl.so.1 Reading symbolic information for libdl.so.1 Reading symbolic information for libw.so.1 (dbx) check -access access checking - ON (dbx) run Running: a.out (process id 15052) Enabling Error Checking... done Write to unallocated (wua): Attempting to write 1 byte through NULL pointer Current function is problem 7 *s = 'c'; (dbx) pop stopped in main at line 12 in file "bug.c" 12 problem(); (dbx) #at this time we would edit the file; in this example just copy the correct version (dbx) cp bug-fixed.c bug.c (dbx) fix fixing "bug.c" ...... pc moved to "bug.c":14 stopped in main at line 14 in file "bug.c" 14 problem(); (dbx) cont execution completed, exit code is 0 (dbx) quit The following modules in \Qa.out' have been changed (fixed): bug.c Remember to remake program.
For more information on using fix and continue, see Memory Leak (mel) Error.
Both leak detection and access checking require that the standard heap management routines in the shared library libc.so be used so that runtime checking can keep track of all the allocations and deallocations in the program. Many applications write their own memory management routines either on top of the malloc() or free() function or stand-alone. When you use your own allocators (referred to as private allocators), runtime checking cannot automatically track them; thus you do not learn of leak and memory access errors resulting from their improper use.
However, runtime checking provides an API for the use of private allocators. This API allows the private allocators the same treatment as the standard heap allocators. The API itself is provided in the header file rtc_api.h and is distributed as a part of Sun Studio software. The man page rtc_api(3x) details the runtime checking API entry points.
Some minor differences might exist with runtime checking access error reporting when private allocators do not use the program heap. The error report will not include the allocation item.
The bcheck utility is a convenient batch interface to the runtime checking feature of dbx. It runs a program under dbx and by default, places the runtime checking error output in the default file program.errs.
The bcheck utility can perform memory leak checking, memory access checking, memory use checking, or all three. Its default action is to perform only leak checking. See the bcheck(1) man page for more details on its use.
Before running the bcheck utility on a system running the 64-bit Linux OS, you must set the _DBX_EXEC_32 environment variable.
bcheck [-V] [-access | -all | -leaks | -memuse] [-o logfile] [-q] [-s script] program [args]
Use the -o logfile option to specify a different name for the logfile. Use the -s script option before executing the program to read in the dbx commands contained in the file script. The script file typically contains commands like suppress and dbxenv to tailor the error output of the bcheck utility.
The -q option makes the bcheck utility completely quiet, returning with the same status as the program. This option is useful when you want to use the bcheck utility in scripts or makefiles.
To perform only leak checking on hello, type:
bcheck hello
To perform only access checking on mach with the argument 5, type:
bcheck -access mach 5
To perform memory use checking on cc quietly and exit with normal exit status, type:
bcheck -memuse -q cc -c prog.c
The program does not stop when runtime errors are detected in batch mode. All error output is redirected to your error log file logfile. The program stops when breakpoints are encountered or if the program is interrupted.
In batch mode, the complete stack backtrace is generated and redirected to the error log file. The number of stack frames can be controlled using the dbx environment variable stack_max_size.
If the file logfile already exists, bcheck erases the contents of that file before it redirects the batch output to it.
You can also enable a batch-like mode directly from dbx by setting the dbx environment variables rtc_auto_continue and rtc_error_log_file_name (see Setting dbx Environment Variables).
If rtc_auto_continue is set to on, runtime checking continues to find errors and keeps running automatically. It redirects errors to the file named by the dbx environment variable rtc_error_log_file_name. (See Setting dbx Environment Variables.) The default log file name is /tmp/dbx.errlog.uniqueid. To redirect all errors to the terminal, set the rtc_error_log_file_name environment variable to /dev/tty.
By default, rtc_auto_continue is set to off.
After error checking has been enabled for a program and the program is run, one of the following errors may be detected:
librtc.so and dbx version mismatch; Error checking disabled
This error can occur if you are using runtime checking on an attached process and have set LD_AUDIT to a version of rtcaudit.so other than the one shipped with your Sun Studio dbx image. To fix this, change the setting of LD_AUDIT.
patch area too far (8mb limitation); Access checking disabled
Runtime checking was unable to find patch space close enough to a load object for access checking to be enabled. See "Runtime Checking Limitations" next.
Runtime checking has the following limitations.
Access checking requires some symbol information in the load objects. When a load object is fully stripped, runtime checking might not catch all of the errors. Read from uninitialized memory errors might be incorrect and therefore are suppressed. You can override the suppression with the unsuppress rui command. To retain the symbol table in the load object, use the-x option when stripping a load object
Runtime checking instruments memory access instructions for access checking. These instructions are handled by a SIGSEGV handler at runtime. Because runtime checking requires its own SIGSEGV handler and signal alternate stack, an attempt to install a SIGSEGV handler or SIGALTSTACK handler results in an EINVALerror or ignoring the attempt.
SIGSEGV handler calls cannot be nested. Doing so results in the error terminating signal 11 SEGSEGV. If you receive this error, use the rtc skippatch command to skip instrumentation of the affected function.
Two problems might arise if sufficient patch area is not available within 8 megabytes of all existing code.
When access checking is enabled, dbx replaces each load and store instruction with a branch instruction that branches to a patch area. This branch instruction has an 8 megabyte range. If the debugged program has used up all the address space within 8 megabytes of the particular load or store instruction being replaced, no place exists to put the patch area. In this case, dbx invokes a trap handler instead of using a branch. The transfer of control to a trap handler is significantly (up to 10 times) slower, but does not suffer from the 8 megabyte limit.
Out Register Override Problem in V8+ Mode
The trap handler limitation affects access checking if both of the following conditions apply:
The process being debugged is instrumented using traps.
The process uses the V8+ instruction set.
The problem occurs because the sizes of out registers and in registers on V8+ architecture are different. Out registers are 64 bits long, while in registers are only 32 bits long. When a trap handler is invoked, out registers are copied into in registers and the higher 32 bits are lost. Therefore, if the process being debugged utilizes the higher 32 bits of out registers, the process might run incorrectly when access checking is turned on.
The compilers use the V8+ architecture by default when creating 32-bit SPARC based binaries, but you can tell them to use the V8 architecture with the -xarch option. Unfortunately, system runtime libraries are unaffected by recompiling your application.
dbx automatically skips instrumentation of the following functions and libraries that are known to not work correctly when instrumented with traps:
However, skipping instrumentation might result in incorrect RTC error reports.
If either of the above conditions applies to your program, and the program starts to behave differently when you turn on access checking, it is likely that the trap handler limitation affects your program. To work around the limitation, you can do the following:
Use the rtc skippatch command (see rtc skippatch Command) to skip instrumentation of the code in your program that uses the functions and libraries listed above. Generally it is difficult to track the problem to a specific function, so you might want to skip instrumentation of an entire load object.
Try using 64–bit SPARC-V9 instead of 32–bit SPARC-V8
If possible, recompile your program for V9 architecture, in which all of the registers are 64 bits long.
Try adding patch area object files.
You can use the rtc_patch_area shell script to create special .o files that can be linked into the middle of a large executable or shared library to provide more patch space. See the rtc_patch_area(1) man page.
When dbx reaches the 8 megabyte limit, it tells you which load object was too large (the main program, or a shared library) and it prints out the total patch space needed for that load object.
For the best results, the special patch object files should be evenly spaced throughout the executable or shared library, and the default size (8 megabytes) or smaller should be used. Also, do not add more than 10-20% more patch space than dbx says it requires. For example, if dbx says that it needs 31 megabytes for a.out, then add four object files created with the rtc_patch_area script, each one 8 megabytes in size, and space them approximately evenly throughout the executable.
When dbx finds explicit patch areas in an executable, it prints the address ranges spanned by the patch areas, which can help you to place them correctly on the link line.
Try dividing the large load object into smaller load objects.
Split up the object files in your executable or your large library into smaller groups of object files. Then link them into smaller parts. If the large file is the executable, then split it up into a smaller executable and a series of shared libraries. If the large file is a shared library, then rearrange it into a set of smaller libraries.
This technique allows dbx to find space for patch code in between the different shared objects.
Try adding a "pad" .so file.
This solution should be necessary only if you are attaching to a process after it has started up.
The runtime linker might place libraries so close together that patch space cannot be created in the gaps between the libraries. When dbx starts up the executable with runtime checking turned on, it asks the runtime linker to place an extra gap between the shared libraries, but when attaching to a process that was not started by dbx with runtime checking enabled, the libraries might be too close together.
If the runtime libraries are too close together, (and if it is not possible to start the program using dbx) then you can try creating a shared library using the rtc_patch_area script and linking it into your program between the other shared libraries. See the rtc_patch_area(1) man page for more details.
Errors reported by runtime checking generally fall in two categories. Access errors and leaks.
When access checking is turned on, runtime checking detects and reports the following types of errors.
Problem: Attempt to free memory that has never been allocated.
Possible causes: Passing a non-heap data pointer to free() or realloc().
char a[4]; char *b = &a[0]; free(b); /* Bad free (baf) */
Problem: Attempt to free a heap block that has already been freed.
Possible causes: Calling free() more than once with the same pointer. In C++, using the delete operator more than once on the same pointer.
char *a = (char *)malloc(1); free(a); free(a); /* Duplicate free (duf) */
Problem: Attempt to free a misaligned heap block.
Possible causes: Passing an improperly aligned pointer to free() or realloc(); changing the pointer returned by malloc.
char *ptr = (char *)malloc(4); ptr++; free(ptr); /* Misaligned free */
Problem: Attempt to read data from an address without proper alignment.
Possible causes: Reading 2, 4, or 8 bytes from an address that is not half-word-aligned, word-aligned, or double-word-aligned, respectively.
char *s = "hello world"; int *i = (int *)&s[1]; int j; j = *i; /* Misaligned read (mar) */
Problem: Attempt to write data to an address without proper alignment.
Possible causes: Writing 2, 4, or 8 bytes to an address that is not half-word-aligned, word-aligned, or double-word-aligned, respectively.
char *s = "hello world"; int *i = (int *)&s[1]; *i = 0; /* Misaligned write (maw) */
Problem: Attempt to allocate memory beyond physical memory available.
Cause: Program cannot obtain more memory from the system. Useful in locating problems that occur when the return value from malloc() is not checked for NULL, which is a common programming mistake.
char *ptr = (char *)malloc(0x7fffffff); /* Out of Memory (oom), ptr == NULL */
Problem: Attempt to read from nonexistent, unallocated, or unmapped memory.
Possible causes: A stray pointer, overflowing the bounds of a heap block or accessing a heap block that has already been freed.
char c, *a = (char *)malloc(1); c = a[1]; /* Read from unallocated memory (rua) */
Problem: Attempt to read from uninitialized memory.
Possible causes: Reading local or heap data that has not been initialized.
foo() { int i, j; j = i; /* Read from uninitialized memory (rui) */ }
Problem: Attempt to write to read-only memory.
Possible causes: Writing to a text address, writing to a read-only data section (.rodata), or writing to a page that mmap has made read-only.
foo() { int *foop = (int *) foo; *foop = 0; /* Write to read-only memory (wro) */ }
Problem: Attempt to write to nonexistent, unallocated, or unmapped memory.
Possible causes: A stray pointer, overflowing the bounds of a heap block, or accessing a heap block that has already been freed.
char *a = (char *)malloc(1); a[1] = "\0'; /* Write to unallocated memory (wua) */
With leak checking turned on, runtime checking reports the following types of errors.
Problem: A possible memory leak. There is no reference to the start of an allocated block, but there is at least one reference to an address within the block.
Possible causes: The only pointer to the start of the block is incremented.
char *ptr; main() { ptr = (char *)malloc(4); ptr++; /* Address in Block */ }
Problem: A possible memory leak. An allocated block has not been freed, and no reference to the block exists anywhere in program memory, but a reference exists in a register.
Possible causes: This can occur legitimately if the compiler keeps a program variable only in a register instead of in memory. The compiler often does this for local variables and function parameters when optimization is turned on. If this error occurs when optimization has not been turned on, it is likely to be an actual memory leak. This can occur if the only pointer to an allocated block goes out of scope before the block is freed.
if (i == 0) { char *ptr = (char *)malloc(4); /* ptr is going out of scope */ } /* Memory Leak or Address in Register */
Problem: An allocated block has not been freed, and no reference to the block exists anywhere in the program.
Possible causes: Program failed to free a block no longer used.
char *ptr;
ptr = (char *)malloc(1); ptr = 0; /* Memory leak (mel) */


text:
Walter Reed National Military Medical Center at Bethesda, MD - List Your Home
List your property and help other military families with their PCS. Simply enter your information below and your property will be posted for as long as it takes. You can add up to 15 photos for your listing after it has been created. For questions or problems please contact customer service at 800-520-0549. There is no charge to upload your listing.

subset: commoncrawl


text:
One person was killed and another flown to the hospital after a crash late Tuesday morning on Interstate 80 West near Bartonsville that tied up traffic throughout Monroe County for hours. Police said a couple from Long Pond in a 2004 Hyundai Santa Fe were traveling west in the right lane on I-80 at mile marker 302 at 11:37 a.m.
One person was killed and another flown to the hospital after a crash late Tuesday morning on Interstate 80 West near Bartonsville that tied up traffic throughout Monroe County for hours.
Police said a couple from Long Pond in a 2004 Hyundai Santa Fe were traveling west in the right lane on I-80 at mile marker 302 at 11:37 a.m.
Video: Watch the aftermath of the crash
A tractor-trailer driver, Baldev Singh, 46, of Richmond Hill, N.Y., was in the left lane when the driver of the SUV, Joseph A. Terlizzi, 76, attempted to change lanes, striking the front passenger side of the tractor-trailer.
Trying to avoid contact with the car, Singh swerved the truck off the road, crossed the grass median and crossed both eastbound lanes, narrowly missing vehicles before coming to rest on the shoulder, facing westbound.
When the SUV hit the truck, it lost control and rolled several times before coming to rest on its roof facing east on the westbound right shoulder.
Terlizzi's passenger, Concetta Terlizzi, 77, was pronounced dead at the scene. Joseph Terlizzi was flown to Lehigh Valley Cedar Crest and is expected to be released after treatment of injuries.
Singh said he had been hauling pasta from Freeland, N.J., to Plainfield, Ind., for Twin Flag Express Inc., based in Noblesville, Ind.
I-80 was closed in both directions while state police investigated. Ripple effects of the crash were seen all over the Poconos, as fire police directed motorists off I-80.
At one point, police radio reports indicated drivers were running the red light at routes 715 and 611 in Tannersville.
People who got off I-80 in Delaware Water Gap said it took about 45 minutes to go three miles to Stroudsburg.
Drivers were reported backing up on Route 209 north to get to Shafers Schoolhouse Road when they saw the traffic congestion leading to I-80.
In South Stroudsburg, cars could be seen going the wrong way from Park Avenue to Broad Street on one-way streets, only to find traffic as bad at the other end.
I-80 eastbound opened about 4 p.m., and westbound lanes finally opened after 5 p.m.
The Monroe County Control Center was still reporting Route 715 and Warner Road were blocked at around 6 p.m.
Traffic continued to be backed up into New Jersey for more than an hour after the westbound lanes opened.
Police were searching for a motorcycle driver who was passing cars on the shoulder of the road.
Among the vehicles caught in the gridlock were Stroudsburg School District buses taking kids home.
"It definitely slows us down," Stroudsburg School District Superintendent John Toleno said. "It takes a lot of patience on the part of our bus drivers, as well as every other motorist who has to deal with it."
Emergency responders had a rough time as well. John Hettler, paramedic with Suburban EMS in Stroudsburg said, "It was hectic. It made responding to calls rough. It kills us whenever traffic gets rerouted through Stroudsburg. There was a guy on West Main Street with chest pain. Our (estimated time of arrival) was so delayed due to traffic that he decided to drive himself to the hospital instead. It's the patients calling 911 who suffer. There's nothing you can do."


text:
Today I was informed that the CDC released preliminary vital statistics for 2006 which includes state-by-state cesarean birth information. Here in Montana the 2006 cesarean rate was 28%, earning us a rank of number 37 (of 51). The national cesarean rate was 31.1%, an all-time high. Although Montana was 3 percentage points below the national average, the rate still exceeded World Health Organization (WHO) recommendations by 13-18%! The WHO determined that when cesarean rates exceed 10-15%, the risks of the surgery outweigh the benefits. It is my understanding from a recent discussion with a hospital administrator that Community Hospital's (Missoula) cesarean rate exceeded 30% in 2006. Missoula's cesarean rate is headed in the wrong direction.
As a woman with one cesarean scar, these statistics are frightening. Is cesarean birth becoming "normal" birth? If one out of three babies is born through major abdominal surgery, then yes, I'd say the norm is swinging that direction. You need to know that the percentage of birth by cesarean has risen 50% in the past decade. This is straight from the horse's mouth! You also need to know that Montana's VBAC (vaginal birth after cesarean) rate in 2005 was only 1%.
For the second year in a row, ICAN has compiled a list of research from the past year that shows cesarean surgery should be used more judiciously and that VBACs should be routine/normal. Currently, more than 300 hospitals across the U.S. ban women from having a VBAC, essentially coercing them into unnecessary surgery and feeding the growing rate of cesarean. Very few Montana women have access to vaginal births after cesarean sections. Only a handful of hospitals across the state allow VBACs – one of those hospitals is Community Hospital in Missoula
In August, the Centers for Disease Control released a report showing that, for the first time in decades, the number of women dying in childbirth has increased. Experts note that the increase may be due to better reporting of deaths but that it coincides with dramatically increased use of cesarean. The latest national data on infant mortality rates in the United States also show an increase in 2005 and no improvement since 2000. "At a time when maternal and infant mortality rates are decreasing throughout the industrialized world, the United States is in the unique position of having both a rapidly increasing cesarean rate and no improvement in these basic measures of maternal and infant health." says Eugene Declercq, Ph.D., Professor of Maternal and Child Health at Boston University School of Public Health.
Another report released in October by the World Health Organization, the United Nations Population Fund, the U.N. Children's Fund, the U.N. Population Division and The World Bank, and published in the Lancet shows that the U.S. has a higher maternal death rate than 40 other countries. "Women in the U.S. think they're getting top notch care, but our death rate for mothers shows otherwise," says ICAN's President, Pamela Udy. The U.S.'s maternal death rate tied with that of Belarus, and narrowly beat out Bosnia and Herzogovena.
Research from 2007 also shows that VBAC continues to be a reasonably safe birthing choice for mothers. "The research continues to reinforce that cesareans should only be used when there is a true threat to the mother or baby," said Udy. "Casual use of surgery on otherwise healthy women and babies can mean short-term and long-term problems." For women who encounter VBAC bans, ICAN has developed a guide to help them understand their rights as patients. The resource discusses the principles of informed consent and the right of every patient to refuse an unwanted medical procedure. Click here for a pdf copy of this important resource.
Women who are seeking information about how to avoid a cesarean, have a VBAC, or are recovering from a cesarean can visit www.ican-online.org for more information, to find a local chapter, and to receive support.
About Cesareans: ICAN recognizes that when a cesarean is medically necessary, it can be a lifesaving technique for both mother and baby, and worth the risks involved. Potential risks to babies include: low birth weight, prematurity, respiratory problems, and lacerations. Potential risks to women include: hemorrhage, infection, hysterectomy, surgical mistakes, re-hospitalization, dangerous placental abnormalities in future pregnancies, unexplained stillbirth in future pregnancies and increased percentage of maternal death. http://www.ican-online.org/resources/white_papers/index.html Mission statement: ICAN is a nonprofit organization whose mission is to improve maternal-child health by preventing unnecessary cesareans through education, providing support for cesarean recovery and promoting vaginal birth after cesarean. There are 94 ICAN Chapters across North America, which hold educational and support meetings for people interested in cesarean prevention and recovery.


text:
God's Love We Deliver
166 Avenue of the Americas
New York, NY 10013
Tel: 212.294.8100
Fax: 212.294.8101
Joan Adler
Carol Alexander
Mitch Applebaum
Victoria Arzano
Gayle Balsky
Vered Behr
Joan Bennett
Lydia Brown
Edward Coffina
George Cominskie
Deborah Corenthal
Brenda Curtis
Debbie Deitcher
Randy Deutsch
George Dussan
Lynda Feld
Daniel Feldman
Richard Fink
Martin Friedman
Kathie Gershuny
Roslyn Gilbert
Denise Gilson
Lisa Glover
Norma Grant
Eleanor Guiterman
Scott Hayter
Joe Hooper
Brian Hotaling
Gerardo Huertas
Kathy Hunt
Linda Irby
Kyler James
Phyllis Kirschenbaum
William Komar
Jicky Leidicke
John Lemien
Irv Lerner
Wing Tat Leung
Dennis Luczak
Laurie Machson
Charles McEwen
John Moore
Michael Morrissey
Don Newcomb
Li Ng
Keith Nicholson
Richard Ophals
Martha Palma
Ann Parker
Edward Prostak
Vincent Rada
Aimee Ross
Judith Schasberger
Evan Schwartz
Raj Singh
Patrick Smith
Suzy Sobel
Angelo Sperrazza
David Stern
James Strickland
Monica Tarver
Klaus Villa
Sylvia Vogelman
Kim Wainwright
Bob White
Every day at God's Love We Deliver, we rely on an army of dedicated volunteers to make sure that every carrot is chopped, every client's question is answered and every meal is packaged and delivered with love. There are some particular days throughout the year though that we need even more help for holidays and special projects.
These are great opportunities for families and corporate groups, as many of these can accommodate children and large teams. If you have any questions about these volunteer events, please contact us at email@example.com or 212.294.8158.
On Thanksgiving 2017 we home-delivered more than 5,000 healthy and delicious holiday meals to our clients, their children and senior caregivers, and their guests, so that no one has to spend the holiday alone. Thank you to our amazing volunteers for helping us cook and deliver this record number of holiday meals, and check out photos from the day here.
Check out our photo galleries from previous Thanksgivings:
Twice a year, God's Love provides its clients with emergency kits of non-perishable goods in the rare event that we are unable to deliver to them due to weather, van trouble, etc. The winter emergency meal kit assembly project takes place in December and the summer emergency meal kit project is held in June. Volunteers are needed to help us assemble and package the boxes for delivery to our clients. View pictures from our last event here.
The Avon Foundation has been a wonderful supporter of God's Love over the years, donating more than $1 million for our services as well as countless volunteer hours. To show our gratitude, we host a cheering station and encourage walkers to sign a special banner. We also prepare the lunches for the walkers and crew at the Closing Ceremony. And, of course, we give them Chuck's delicious brownies! Email us at firstname.lastname@example.com to get involved. View pictures from our last Avon weekend here.
We believe what makes God's Love so special is the personal touch we add to every meal. This includes special meals on holidays and a personalized cake for each client on his or her birthday. To accompany the cake, we include birthday cards and to accompany our holiday meals, we package them in decorated holiday bags, all made by local elementary and high school students. If you are interested in getting your child, classroom, afterschool program or scout troop involved in this project, contact us at firstname.lastname@example.com or 212.294.8158.
One of the best features of our new building is our rooftop herb garden. Our volunteer gardeners help plant and maintain the beds. Email us for more information.
Tel: 212.294.8102
Tel: 800.747.2023
Fax: 212.294.8198
Fax: 212.294.8101
Community Partners
(MLTC Program)
Tel: 212-294-8187
Fax: 212-294-8189
Tel: 212.294.8103
Fax: 212.294.8198
Tel: 212.294.8158
Fax: 212.294.8139
Tel: 212.294.8142
Fax: 212.294.8101
What is the age requirement for volunteers?
Where is God's Love located?


text:
|Today's post is a repost from 2006.
I'm surrounded by cats and dogs in the studio.
|Today's post is a repost from 2006.
I'm surrounded by cats and dogs in the studio.
Thank you so much for your lovely blog....I just returned from Paris and You are what keeps me going until I return.....I can hardly believe that I can not just walk down 4 flights of stairs and go and get my croissants !!!ReplyDelete
I never like my greens when I try to paint:) never..Poor you and your box regret..It looks rich and decadent..
Did you get your new camera I forgot my other daughter has a small canon..great pics too:)
Love the L paraphernalia and your art work ..of course..
I have a similar green pot from my friend Nancy..she painted her ex home all green..so pretty it turned out!
I just LOVE that green in its various forms here...so pleasant & uplifting...ReplyDelete
LOVE this pale pale green
Perfect for weddings!
What a shame you missed out on the little green box! you won't do that again will you. Love the pale, pale shades of green.ReplyDelete
Thanks Lillian,
This is a repost from 2006
I have way too many pale green boxes at this point! :)
When I was growing up in the 1960s I heard this color called Sea Foam Green.
Now I'm grown up and I've seen seven seas and I've never seen sea foam that color -- which only makes it more magical.
it's a gorgeous, very french green. sometimes also called "eau de nil"? love that name.
bon retour a paris - sounds like you've unearthed some new good places for us! can't wait.
Exactement Paradis!
'Eau de Nil' is it....
though I somewhat doubt the Nile is this pale, soft greeny color...
tell me I'm wrong.
The matching color by punching a hole in sample is brilliant!
I will teach my students that, with credit to PB of course,
thank you,
Maud Guilfoyle
It's an old, old trick Maude
You used to be able to buy Value cards and they had little holes punched out to check the grays.
I love lavender and mint green together. Beautiful watercolor and beautiful photos!
The daughter of friends, Ginger, met a Frenchman when they visited France a few years ago. She didn't speak any French, but fortunately, he could speak English. They ended up getting married, and lived in southern France for a couple of years. They just moved here in Michigan, because they could get better jobs. We were able to see them this past Sunday, and of course, I had to talk about macarons. Willy, his nickname, said he thought Laduree made the best macarons in France. He talked about all the beautiful colors. Man. It was so nice to talk to a real Frenchman!
what a story!
choosing Michigan over Provence????
to make a living vs. living in the French style
Oh my this has got to be my most FAVORITE post of yours, completely on the basis of color:D That green is amazing!!! I adore Tiffany's blue but that green is to DIE for, Carol! Its such a fine line mixing greens because it can go oh-so wrong ;) I agree about it looking apple green. I am surprised there is such a big difference in between the tag and the napkin. neverthe less, i love them both. Thank you for a fix of verte this morning. have a great day!ReplyDelete
Love the apple green post! Wonderful little watercolor! Every time I visit you I want to pick up my paints. Very inspiring!ReplyDelete


text:
DANSVILLE � After more than a decade of being a part of the Dansville Central School District, Amy Schiavi announced her resignation as principal of grades seven through nine today.
Schiavi began her career at Dansville as a seventh grade math teacher in 2000, she also worked as an eighth grade math teacher before being promoted to her current position as principal. Prior to working at DCS, Schiavi taught at Crestwood Children�s Center in Rochester.
"I care deeply for the children and families I have come to know in the Dansville community, and I leave with fond memories of the time I spent here," Schiavi said. "I�m thankful for the opportunities that have been provided, the support I received and the opportunity to work with such a talented group of individuals."
Dr. Paul Alioto, Dansville superintendent, described Schiavi as a courageous educational leader.
"The greater the challenge, the greater her resolve," he said. "Our school community has benefited from Ms. Schiavi�s leadership and we are very grateful for her service to the children and families of Dansville."
Schiavi will end her career at Dansville on Feb. 7 and then move on to the Rochester City School District where she will serve as chief of secondary schools.
Michael Falzoi, co-principal with Schiavi, will assume leadership responsibilities for the entire secondary program. The district will fill the vacant administrative position with an interim administer.


text:
The New Homesteaders
For three years in the 1970's I lived off the grid, in a drafty log cabin south of Ishpeming in the Upper Peninsula. Without electricity, plumbing, running water or natural gas, my husband and I burned wood in an inefficient old Round Oak Duplex for heat, hauled water from the lake and used kerosene lamps for light. But then we gave up. It was too hard.
We knew others who were doing the same thing, struggling to live on land they'd bought cheap in the U.P. Recently I tried to find some of the original group. But, after 30 years, hardly anybody was left. Instead, I found a different community of people living off the grid in the Huron Mountains near Big Bay. I was eager to see how these people were coping. Following are the stories of three families who chose to buck convention, consumerism and convenience for a different, simpler life – unplugged, empowered and closer to the earth.
Jan Zender, Rochelle Dale and Kalil
Jan Zender, Rochelle Dale and their daughter, Kalil, live three miles from the nearest plowed road, at the dead end of a rough two-track. Most cars bottom out while crossing the trail's bridgeless ditches eroded by runoff flowing down the hills toward the Yellow Dog River. After the snows start, no cars come in, and the two-track becomes the family's snowmobile trail.
The countryside is dauntingly hilly, with snow so deep that, on the winter day I visit, a wolf had taken advantage of the hard-packed route. Jan slows the snowmobile so we can watch its fresh tracks run for about a mile before veering off toward the river.
They chose the land, 90 acres, 18 years ago because it has good moving water – a river, springs – not the standing water on the cheaper land where mosquitoes drive people and animals crazy. We ride through a mixed forest of aspen, pine and maple trees – good for building material and firewood.
Jan and Rochelle make their living creating museum-quality replicas of items from the 18th- and 19th-century frontier lifestyles. The vocation flows from their passionate interest in that period, and their daily lives embody that same passion. The cabin is nearly round, like a teepee, with a door on the east side. It's built of poplar logs with broad overhangs, a skylight and a roof nailed on by the couple's mothers. Jan wanted a dirt floor, but Rochelle insisted on wood. While building the house, they lived in a wigwam on the property during summer and in town in the winter. Their son, Ian, played in the forest and helped his mother cook on an outdoor stove. He has since grown and moved away, a musician making his way.
During the past 18 years, the family added a few modern conveniences, choosing carefully. I'd called them on their cell phone when I arrived at the snowmobile trailhead. They have a clock, flashlights, a kerosene refrigerator. A power outlet lies on the floor of the root cellar under the house, connected to an outside generator for vacuuming and power tools. Solar panels power other outlets for listening to National Public Radio shows like "The Thistle & Shamrock" and "Mountain Stage."


text: Last month in a post on our blog, we referenced a video interview with Jesse James Garrett, author of The Elements of User Experience. In this interview, Garrett points to a trend among technology companies in which they are now starting to invest heavily in developing and improving user experience (UX). In that post, we shared that we often talk with publishers who are struggling to balance user experience with monetization.Distracting, often irrelevant display ads have a way of pulling attention away from a site's content and negatively impacting user experience. Some publishers maintain the false perception that they need to choose between either readers or revenue. While that may have been the case years ago, today there are monetization tools that fit seamlessly into a site's content with negligible impact on UX and solid revenue generating potential. An example of one of these tools, of course, would be VigLink.We weren't surprised when we came across a whole slew of recent articles addressing what is now being called "native advertising" or "native monetization." What we realized is that times they are a-changin' when it comes to what readers expect when they visit a site. No longer are they willing to put up with things like pesky pre-rolls and flashing banners. For this reason, Choire Sicha argues in his article "The Pretty New Web and the Future of Native Advertising," the internet has changed. "It's an internet where [display] ads are considered no better than spam."How, then, are publishers going to make money off their sites, and how are advertisers going to reach their audience? As it turns out, "the hot word in advertising right now is 'native,'" Sicha divulges. "All native means is that advertisers are now getting to come closer to presenting advertising that is less distinguishable from what they like to call 'content.'" What does that mean for publishers? It means that many advertisers and merchants no longer want to pay a premium to be present around your content, but rather, they want to pay to be present in your content.Thanks to this dramatic shift in reader expectations, "for the first time in digital ad history, a publisher's revenue model is now aligned with user experience," Dan Greenberg contends in his article "Why Native Ad Formats Are the Future." "Instead of alienating viewers with ads they don't want to see – and interrupting the content experience they came to the site to experience – now publishers can integrate sponsored content seamlessly throughout their sites."For publishers, this means you're ahead in the revenue game by having chosen to implement VigLink. As you consider your published content, remember to focus on new user expectations, native monetization, and "the pretty new web." Whitney Smith, VigLink Marketing Communications Manager


text:
Patrol Leader
From MeritBadgeDotOrg
Revision as of 16:22, October 8, 2007 by Scoutersig (Talk | contribs)
A Patrol Leader is the elected leader of a Scout patrol, the base unit of a troop and the key to the patrol method. He is a voting member of the Patrol Leaders' Council, reporting to the Senior Patrol Leader. With approval of the Senior Patrol Leader and Scoutmaster, he appoints an Assistant Patrol Leader.
- Plan and lead patrol meetings and activities.
- Keep patrol members informed.
- Assign each patrol member a specific duty.
- Represent your patrol at all patrol leaders' council meetings and the annual program planning conference.
- Prepare the patrol to participate in all troop activities.
- Work with other troop leaders to make the troop run well.
- Know the abilities of each patrol member.
- Set a good example.
- Wear the Scout uniform correctly.
- Live by the Scout Oath and Law.
- Show and develop patrol spirit.
Scouting.org Patrol Leader page Troop 615 of League City, Texas
Chair: Senior Patrol Leader
Members: Patrol Leaders, Assistant Senior Patrol Leader(s), and Troop Guides
Other Members May Include: Instructor(s), Quartermaster(s), Scribe, and other Positions of Responsibility
Advisors: Scoutmaster, Troop Committee Chair, Assistant Scoutmasters


text:
SeaChanger's Light Emitting Plasma Technology Featured in Historic Paris Museum
Vibrant colored lighting minimizes energy consumption, heat load on fragile artifacts
Largo, Florida (October 16, 2012) – France's natural history museum has renovated its lighting system to include SeaChanger's Light Emitting Plasma (LEP) Color Engines, citing the product's incredible color palette and high-energy efficiency.
The Grande Galerie de l'Evolution of the Muséum National d'Histoire Naturelle in Paris has origins dating back more than 375 years. Its previous lighting system had extremely high maintenance and daily use costs, said Pierre de Cazenove, the museum's head of operations and planning for exhibits. The move to SeaChanger LEP is part of the museum's effort to conserve energy and use long-lasting light sources that won't harm delicate museum pieces.
SeaChanger's color engine, designed to be utilized with ETC Source Four optical components, provides professional lighting for theaters, museums and architectural installations around the world. The LEP can crisply illuminate the museum's artifacts from throw distances of 35 meters, a range not reachable by LED products without significant loss of illumination. The SeaChanger Plasma's light source puts out low ultraviolet and infrared light that does not damage the displays, and its energy-efficient plasma source reduces energy consumption and heat load, a necessity when displaying artifacts dating back to the late 1600s.
"Light Emitting Plasma is a real alternative to conventional light sources: halogen, LED or discharge lamps," said Jean Louis Pernette, managing director of AVAB, a SeaChanger and ETC distributor. "The compromise between light output, power used and lamp life is unique and perfectly meets the museum's specifications."
The museum illuminates some of its biggest attractions with SeaChanger LEP such as its large caravan of African animals; desert, marine and polar spaces; and a whale skeleton. The museum is continuing to convert its lighting to SeaChanger units. When complete, savings will total more than $38,000 per year because of infrequent re-lamping and reduction of electricity consumption.
SeaChanger's Light Emitting Plasma 320-watt lamp produces 10,000 lumens of light performing at more than 31 lumens per watt with a lamp lifespan of 15,000 hours. It is convection-cooled and silent, with smooth, swipe-free color transitions and a color rendering index of 92. The dichroic filters provide better color re-creation than colored LEDs that will color degrade over time, and their resistance to temperature and humidity assures color consistency for the life of the fixture.
SeaChanger will present its products in Booth #1113 at the LDI 2012 show in Las Vegas from Oct. 19 to Oct. 21.


text:
NPD has revealed its March US retail sales data, and as several analysts predicted, despite BioWare's Mass Effect 3 topping the charts, overall it's not pretty. Total game industry sales dropped 25 percent to $1.1 billion, as total software across consoles, portable and PC fell 26 percent to $585.1 million, while hardware sales plunged 35 percent to $323.5 million.
So all of the hardware dropped for consoles as well as for it's software. Interesting...
The retail picture for the industry is going to continue to be ugly. Digital is becoming more and more important and NPD doesn't offer any monthly digital data.
EDIT: On a side note, as a baseball nut and a HUGE fan of MLB The Show, very happy to see it doing well on the charts.
582k copies of Raccoon City sold. Looks like Slant Six gets the last laugh.
There wasn't any games worth getting aside from Mass Effect 3. I mean there are some niche titles, but when a bad game like Raccoon City is getting crazy sales like it is, you know gamers are starving for new games.
I don't know why publishers all release their games so late in the year, I wish they would spread them out a bit more like last year. I mean didn't we have a lot more as far as quality games around this time last year? L.A. Noire, Portal 2, Crysis 2 and Homefront I believe all released early in the year.


text:
MLB average salary up to $3.2M
Baseball's average salary increased 3.8 percent this year to a record $3.2 million.
Article continues below ...
According to final figures released Friday by the Major League Baseball Players Association, the rise was the steepest since 2007. The boost was helped by an increase in the minimum salary from $414,000 to $480,000.
The New York Yankees had the highest average for the 14th consecutive season at $6.88 million, rising after consecutive declines from a peak of $7.66 million when they won the World Series in 2009.
The Los Angeles Dodgers rose from 13th to second at $5.55 million and Texas from 15th to fifth at $4.89 million.
At nearly $685,000 Houston had the lowest average since the 2006 Florida Marlins.


text:
RESEDA >> A police officer and another man were injured and a suspect was in custody following Monday morning shootings in Reseda that caused major street closures for most of the day.
Los Angeles Police Department West Valley officers responded to a call at 9:34 a.m. of an assault with deadly weapon in progress in the 7100 block of Yolanda Avenue. While responding to the call, officers learned that there was a man armed with a handgun and had a pit bull, said LAPD Cmdr. Andrew Smith.
The officers found a man had been shot once in the arm and once in the leg and were directed by citizens to an individual who was running away, Smith told reporters at the scene.
The officers confronted the man, who turned and "fired multiple rounds at our police officers in their vehicle," Smith said.
One officer sustained an injury to his right arm but Smith said he could not say whether that was caused by a bullet, a bullet fragment or a fragment of the vehicle. The officer was transferred to the hospital in "good condition" and later released. The officer, a seven-year-veteran of the department, returned to the scene to help detectives, he added.
The other man who was shot was in stable condition as of Monday afternoon and was able to talk, Smith said. Smith did not know what prompted the original shooting and whether the two men had previously been associated in any way.
After the 49-year-old suspect, who was not immediately identified, fired at the officers, he was taken into custody and the handgun — a blue steel semi-automatic handgun — was recovered at the scene, he said. The suspect was not injured.
Smith could not say Monday whether the officers returned fire or not. He said the matter was under investigation by the LAPD's Robbery-Homicide Division.
Sherman Way was closed from between Reseda Boulevard and Rhea for most of the day as the investigation continued.
No other suspects were outstanding. The pit bull, which was unharmed, was also taken into police custody and was going to be turned over either to a family member of the suspect or a shelter, Smith said.
John Levy of Encino said he had just left a medical building on Sherman Way and was walking toward his car when he said he heard a total of about five shots fired. He took refuge in a nearby parking lot.
After hearing the shots, he said he spotted the police SUV that was targeted by the suspect and multiple police cars then showed up "in a very, very short time."


text:
BRUSSELS (AP) — European Union countries are dragging themselves to a year-end summit with a heavy load of unfinished business aimed at shoring up confidence in the region in the wake of the three-year financial crisis.
The 27 finance ministers remained split Tuesday on the establishment of a new European single supervisor to keep wayward banks in check, and were forced to squeeze in another extraordinary meeting next week on the eve of a Dec 13-14 summit of EU leaders in Brussels.
Add to that deep-rooted disagreements on the establishment of a multi-annual EU budget and the seemingly endless strife to keep Greece on the safe side of the brink of bankruptcy, and it adds up to a chaotic outlook for the EU over the next weeks.
The establishment of a banking union, in particular, includes some decisions that have to be taken by Dec. 31. The supervision of EU banks to rein in reckless action is key to that.
"I want to stress that if that would not happen that would be bad in terms of the market reactions," European Central Bank Vice President Vitor Constancio told Tuesday's meeting of finance ministers.
As part of its plans to avoid a repeat of the financial crisis crippling the region, the EU has been working toward setting up a "banking union" — a unified playbook for all the region's banks. The single bank supervisor is a vital part of this plan and must be up and running before other measures can be introduced: European-wide depositors' insurance; a single method for winding down bankrupt banks; and allowing the European bailout fund to directly help banks in trouble, instead of lending money only to governments.
And this time it is disagreement between the two traditional drivers of European integration — France and Germany — that is at the heart of the delays.
The continent's two largest economic powers are divided over how many banks the supervisor would be allowed to oversee and what powers the ECB should have within the supervision.
"The position of France is steadfast. It is all banks that are covered by the banking supervision," said French Finance Minister Pierre Moscovici.
German Finance Minister Wolfgang Schaeuble said "it would be very difficult to get approval by the German parliament if (the deal) would leave the supervision for all the German banks to European banking supervision."
"Nobody believes that it would work," Schaeuble said. Germany has hundreds of local banks which operate differently from large multinationals like Deutsche Bank. Schaeuble has been pushing for the new supervisor to oversee only the few dozen largest banks in Europe.
On top of that, he said the ECB had to remain at arm's length from any supervisory decision-making it takes on to protect its independence. The ECB sets monetary policy for the 17 EU countries that use the euro and is committed to remain independent of political pressure. Germany fears the ECB's independence may be lost if it has to negotiate the bailout of a bank in one of the member states.
"The last decision cannot be left to the governing council of the ECB," Schaeuble said of bank bailouts.
In contrast, Moscovici came out strongly for an agreement with the ECB in the driver's seat.
He advocates supervision of all 6,000 institutions that have a banking license in the EU.
"In the end, it must be the ECB that has the responsibility on the whole. Otherwise, there is no real system of banking supervision," Moscovici said.
The banking sector has been seen as a prime cause of Europe's three-year crisis and agreement to fix it as an essential part to avoid a recurrence.
Not only have banks taken on bad investments, but national supervisors have often been reluctant to impose restructuring plans on them, particularly since many banks operate across borders. A common European supervisor, proponents say, would bypass the national politics and do what is needed to keep the continent's financial sector healthy.
The 10 EU nations not using the euro want to be included in a banking union to create a level playing field within the full EU. But some countries, including the U.K. and Sweden, also worry it could stifle their financial sectors if too harsh.
European leaders have agreed, in theory, to cede significant amounts of sovereignty to fix the banking issue and runaway spending of several member states.
As so often before, the practical implementation has proved difficult. The crisis has highlighted the many divisions within the EU, critics say, at a time when a strong and united vision was needed.
Closer banking and monetary cooperation will be a key topic at next week's summit meeting of EU government leaders, and a deepening rift between traditional allies France and Germany would complicate progress.
On the EU budget, differences have been running even deeper, with Germany leaning closer to Britain on keeping spending under tight control to match the austerity drive of many member states. France has been leaning closer to the nations urging sustained investment to boost growth.
Those disagreements are so vast that a special summit will likely not be called before next February.
Don Melvin contributed to this article.


text:
|Episode Description
|Wednesday, Feb 27, 2013 - 6:00 PM
"USA: Oh, Those Ravioli"
Lidia heads north to Boston, where she takes viewers on a sweet trip to two Boston pastry shops: Modern Pasty and Maria's Pastry, and ventures into Boston's Little Italy to see pasta made by hand. Down in New Jersey, Lidia checks out Simply Grazin' Organic Farm. In the kitchen, Lidia prepares Ricotta and Sausage-Filled Ravioli and Struffoli, an Italian-American classic, for dessert. D
|More on LEARN/CREATE (MT)
|No upcoming shows in database
|Previous on LEARN/CREATE (MT)
|No Past shows in database


text:
George W. Bush heads to Leno's stage next week
LOS ANGELES (AP) — Former President George W. Bush is headed to "The Tonight Show" next week to talk about his post-White House years with Jay Leno, NBC said Tuesday.
The 43rd president has kept a mostly low profile since exiting office in early 2009 while the country was in two wars and struggling with an economic crisis. But he made headlines in July by urging Congress to reach a "positive resolution" on immigration reform, an issue that eluded him during his presidency, and he also appeared in Africa with President Barack Obama at a ceremony to remember victims of terrorism.
Bush, a 67-year-old grandfather, is scheduled to appear on Leno's couch Nov. 19. It will be the fourth time that Bush has been a guest on Leno's show since his first appearance during the 2000 campaign season.
Bush left the White House with abysmal approval ratings, but polling has suggested some Americans are gradually softening their views of him. His presidential library was dedicated in Texas this year, where former President Bill Clinton joked with Bush about his newfound hobby of painting.
He told ABC earlier this year he wants to "stay out of the limelight."


text:
We followed the maverick campaigns of Dartmouth alums Peter Robinson and Todd Zywicki for election to the Dartmouth board of trustees with great interest. I wrote about their nascent campaigns in "Bucking the deans at Dartmouth" for the Standard and celebrated their election here this past May in "Green dreams come true."
Robinson and Zywicki followed the long-established procedures for election to the alumni seats on the college's board. The lesson the college has taken from the election is apparently that it is the procedures rather than the college that need to be reformed. This morning Dartmouth undergradaute Joe Malchow of Joe's Dartblog writes:
…it doesn't look good when you change the rules afterwards. I want to give you a heads up on this. T.J. Rodgers, Robinson, and Zywicki won the last three elections for Dartmouth trustees. They were all petition candidates. Alumni very clearly voiced dissent by strongly and consistently voting for the non-establishment candidates. And it was a watershed moment, inspiring similar "discoveries" of petition clauses in other college's charters.
Now, very quietly, a new constitution has been drafted with outrageous new rules for trustee elections. Put simply, the college wants to make it so that another Peter Robinson or another Todd Zywicki can't happen. And indeed, under these rules their wins would have been practically impossible.
I post a PDF of the proposed constitution and look at many of its problems at the post below, and alum Joe Asch has also helped initiate the debate with a column in the student newspaper this AM.
Joe's post is "As though a rose should shut and be a bud again." The Dartmouth Daily article by Joseph Asch is "Changing the rules."


text:
Bariatric & Minimally Invasive Surgery
Brain & Spine Institute
Cancer Institute
Cardiovascular Institute
ER-7 Emergency Center
Hospitalist Program
Krieger Eye Institute
Physical Medicine and Rehabilitation
Rubin Institute for Advanced Orthopedics
Sleep Centers
Spine Centers
Vascular Institute
Additional Services
Adult Hydrocephalus
Brain & Spine Institute
Cancer Institute
Cardiovascular Institute
Children's Hospital
ER-7 Emergency Center
Geriatric Surgery
Joint Preservation and Replacement
Krieger Eye Institute
Limb Lengthening
Rubin Institute for Advanced Orthopedics
Sleep Center
Stroke Center
Vascular Institute
Women's Services
Additional Services
Bariatric & Minimally Invasive Surgery
Brain & Spine Institute
Breast Care Center
Cancer Institute
Cardiovascular Institute
Center for Diabetic Limb Preservation
Cosmetic Surgery
ER-7 Emergency Center
Krieger Eye Institute
Psychiatric Services
Sleep Center
Rubin Institute for Advanced Orthopedics
Vascular Institute
Women's Wellness Center
Wound Care & HBOT
Additional Services
About LifeBridge Health
Annual Report 2016
At a Glance (PDF)
Freedom To Be Green
LifeBridge Health Magazine
LifeBridge Health Medical Care Partners
Medical Missions at LifeBridge Health
Population Health
Department of Research
Government and Community Relations
LifeBridge Health Board of Directors
LifeBridge Health Management Team
LifeBridge Health
Sinai Hospital
Northwest Hospital
Carroll Hospital
LifeBridge Health Development
Contact Us
Development News
Donate Now
Grateful Patient Stories
Special Events
Ways to Give
Get In The Game - Employee Giving Campaign
Volunteer at Sinai Hospital
Volunteer at Northwest Hospital
Volunteer at Carroll Hospital
Volunteer at Levindale
Campus Map
Dining - Patient Room Menus
Dining - Retail
The Hackerman-Patz House
Important Phone Numbers
Outpatient Pharmacy
Retail Shops
Visiting Hours
Wireless Internet
For more Sinai Hospital
patient and visitor information,
click here.
Campus Map
Dining - Patient Room Menus
Dining - Retail
Gift Shop
Important Phone Numbers
Outpatient Pharmacy
Visiting Hours
Wireless Internet
For more Northwest Hospital
patient and visitor information,
click here.
Campus Map
Gift Shop
Important Phone Numbers
Visiting Hours
For more Carroll Hospital
patient and visitor information,
click here.
Care Management Services
Community Calendar
Contact Us
Important Information
Health Library
Insurance Plans Accepted
Laboratory Locations
LifeBridge Health Partners
LifeBridge Health Magazine
Maryland Health Connection
My LifeBridge Health Patient Portal
Newsletter Archive & Signup
News Room
Outpatient Pharmacy
Population Health
Recorded Webinars
Social Media
Vendor Resources
WBAL-AM Videos
As one of the largest, most comprehensive and most highly respected providers of health-related services to the people of northwest Baltimore, LifeBridge Health advocates preventive services, wellness and fitness services, and educational programs.
LifeBridge Health consists of Sinai Hospital of Baltimore, Northwest Hospital, Carroll Hospital, Levindale Hebrew Geriatric Center and Hospital, and its subsidiaries and affiliated units, including LifeBridge Health & Fitness and the LifeBridge Medical Care Centers in Eldersburg, Mays Chapel and Reisterstown. Sinai Hospital, Northwest Hospital and Carroll Hospital are all acute-care general hospitals with complementary clinical centers of excellence.
To improve the health of the individuals and communities we serve through compassionate, high quality care.
To be a nationally recognized, independent health system consistently providing outstanding quality, service, affordability and outcomes.
LifeBridge Health is dedicated to advancing the health of the community through a variety of health and wellness programs and services. The Wellness Division of LifeBridge Health, through LifeBridge Investments Inc., owns and operates several subsidiaries that provide such services to the community.
LifeBridge Health & Fitness provides a wide array of fitness programs and was one of the first facilities in the country to fully integrate rehabilitative and clinical health programs in a community-based fitness facility. It offers a range of specialized institutes of health for individuals with special health care needs, including cardiovascular prevention and rehabilitation, pulmonary therapy, Parkinson's therapy, and programs for those with diabetes and arthritis. Located in Pikesville, LifeBridge Health & Fitness has been selected as "Baltimore's Best" health and fitness center by Baltimore magazine and is recognized as a national model for wellness.
LifeBridge Corporate Health provides health and wellness programs for corporations, government agencies and community groups. As Maryland's first comprehensive, hospital-based provider of corporate fitness management and wellness services, LifeBridge Corporate Health's philosophy is that wellness is a lifestyle. It promotes physical, emotional, intellectual, social and spiritual health through a variety of programs offered onsite to employees and community members.
Sinai Hospital, Northwest Hospital, Carroll Hospital and Levindale depend upon the generosity of those whom they serve, and others in the community, to sustain their missions. For information on donating to LifeBridge Health, please visit our fundraising page or call 410-601-GIFT.
LifeBridge Health
2401 W. Belvedere Ave.
Baltimore, MD 21215
Contact Us: 410-601-9000
Subscribe to our monthly newsletter
Terms of Use | Privacy Policy | HIPAA Notice of Privacy Practices | Transportation Policy |
Nondiscrimination Notice and Foreign Language Assistance