Opened 9 years ago

Closed 6 years ago

#1073 closed defect (fixed)

G_fatal_error segfault outside of GRASS session

Reported by: kyngchaos Owned by: grass-dev@…
Priority: normal Milestone: 6.4.4
Component: LibGIS Version: 6.4.0 RCs
Keywords: G_fatal_error() Cc:
CPU: OSX/Intel Platform: MacOSX

Description

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.

Change History (6)

comment:1 in reply to:  description ; Changed 9 years ago by 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.

comment:2 Changed 8 years ago by hamish

Component: DefaultLibGIS
Keywords: G_fatal_error() added

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

comment:3 in reply to:  2 Changed 8 years ago by 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

comment:4 in reply to:  1 ; Changed 7 years ago by neteler

Milestone: 6.4.06.4.4

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.

comment:5 in reply to:  4 Changed 7 years ago by 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

comment:6 Changed 6 years ago by neteler

Resolution: fixed
Status: newclosed

Backported to relbr64 in r60002

Tested with (as per comment:2)

export -n GISBASE GISRC ; g.version -r

No more segfault. Closing.

Note: See TracTickets for help on using tickets.