G_fatal_error segfault outside of GRASS session

[kyngchaos]

When any module is run outside of a GRASS session, G_fatal_error itself segfaults. This causes a loop for a while until the system gives up.

From the OSX crashlog:

OS Version:      Mac OS X 10.6.3 (10D573)
Report Version:  6

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_PROTECTION_FAILURE at 0x00007fff5f3fec50
Crashed Thread:  0  Dispatch queue: com.apple.main-thread

Thread 0 Crashed:  Dispatch queue: com.apple.main-thread
0   libgrass_gis.dylib            	0x000000010006d364 vfprint_error + 20
1   libgrass_gis.dylib            	0x000000010006db22 G_fatal_error + 170
2   libgrass_gis.dylib            	0x000000010006d046 G_getenv + 37
3   libgrass_gis.dylib            	0x000000010006d468 vfprint_error + 280
4   libgrass_gis.dylib            	0x000000010006db22 G_fatal_error + 170
5   libgrass_gis.dylib            	0x000000010006d046 G_getenv + 37
6   libgrass_gis.dylib            	0x000000010006d468 vfprint_error + 280
7   libgrass_gis.dylib            	0x000000010006db22 G_fatal_error + 170
...

This repeats for about 510 lines. I believe it should be printing a message that I need to run the module within a GRASS session.

[glynn]

Replying to kyngchaos:

When any module is run outside of a GRASS session, G_fatal_error itself segfaults. This causes a loop for a while until the system gives up.

In 7.0, r40465 was made to protect against infinite recursion. At that time, it was determined that the issue couldn't arise with 6.x, but either that was incorrect or something has changed.

AFAICT, the issue is due to log_error calling G_gisbase(); I have no idea why it's doing this, as it uses the result as a truth value, but G_gisbase() ends up calling G_fatal_error() if GISBASE is unset.

In any case, something similar to r40465 will work for 6.x.

[hamish]

still happening?

I get a complaint about "error while loading shared libraries, cannot open shared object file: No such file or directory" if I try to run a C module outside of a GRASS session.

Hamish

[glynn]

Replying to hamish:

I get a complaint about "error while loading shared libraries, cannot open shared object file: No such file or directory" if I try to run a C module outside of a GRASS session.

That's to be expected; the loader needs LD_LIBRARY_PATH (DYLD_LIBRARY_PATH on OSX, PATH on Windows) to be set in order to locate the GRASS libraries.

To check for this specific issue, either set PATH and LD_LIBRARY_PATH (etc) manually, or start a GRASS session then manually unset GISBASE and GISRC with:

export -n GISBASE GISRC

[neteler]

Replying to glynn:

Replying to kyngchaos:

When any module is run outside of a GRASS session, G_fatal_error itself segfaults. This causes a loop for a while until the system gives up.

In 7.0, r40465 was made to protect against infinite recursion. At that time, it was determined that the issue couldn't arise with 6.x, but either that was incorrect or something has changed.

Backported to 6.5.svn in r52774. Still open for 6.4.svn.

[hamish]

Replying to neteler:

Replying to glynn:

Replying to kyngchaos:

When any module is run outside of a GRASS session, G_fatal_error itself segfaults. This causes a loop for a while until the system gives up.

In 7.0, r40465 was made to protect against infinite recursion. At that time, it

was determined that the issue couldn't arise with 6.x, but either that was

incorrect or something has changed.

Backported to 6.5.svn in r52774. Still open for 6.4.svn.

to do now or later?

H

[neteler]

Backported to relbr64 in r60002

Tested with (as per comment:2)

export -n GISBASE GISRC ; g.version -r

No more segfault. Closing.