Problem with GPS under MacOS

Problem with GPS under MacOS

[Laurent]

Hi

I have the problem that when I work with GPS and Gnoga is with'ed that GPS 2017 is crashing. In the log I have this:
-----------------------------------
Process:               gps_exe [7461]
Path:                  /usr/local/gnat/bin/gps_exe
Identifier:            com.adacore
Version:               6.0.1 (6.0.1)
Code Type:             X86-64 (Native)
Parent Process:        ??? [1]
Responsible:           gps_exe [7461]
User ID:               501

Date/Time:             2017-08-17 21:42:20.931 +0200
OS Version:            Mac OS X 10.11.6 (15G1611)
Report Version:        11
Anonymous UUID:        5A0FB384-243D-4BD4-E463-DF298380860D


Time Awake Since Boot: 12000 seconds

System Integrity Protection: enabled

Crashed Thread:        0  Dispatch queue: com.apple.main-thread

Exception Type:        EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:       KERN_PROTECTION_FAILURE at 0x00007fff5f3ffe50
Exception Note:        EXC_CORPSE_NOTIFY

VM Regions Near 0x7fff5f3ffe50:
    Stack                  00007000010f1000-0000700001173000 [  520K] rw-/rwx SM=COW  thread 12
--> STACK GUARD            00007fff5bc00000-00007fff5f400000 [ 56.0M] ---/rwx SM=NUL  stack guard for thread 0
    Stack                  00007fff5f400000-00007fff5fbf1000 [ 8132K] rw-/rwx SM=COW  thread 0

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libgnat-18.dylib              	0x000000010b1237cb system__finalization_masters__finalize + 27
1   gps_exe                       	0x00000001004a1d68 ada_semantic_tree__units__get_owning_unit + 1432
--------------------------
I thought to have solved this problem.

It happens when I want to type something.

GPS 2016 seems to have the same problem but I get a beachball of death and so no crashlog.

Googling for a solution didn't really help. 32bit apps are limited by the kernel to 64MB of stack memory which are actually closer to 58MB. 

A solution would be to recompile the kernel. Hm well not really helpful.

The other solution would be to recompile the GPS with a greater stack. Hm not really helpful either.

Or using Linux. Possible but only if there is no other solution.

Are there other things I could try?

Thanks

Laurent

Re: Problem with GPS under MacOS

[Robert Eachus]

On Thursday, August 17, 2017 at 4:48:02 PM UTC-4, Laurent wrote:
> Hi
> 
> I have the problem that when I work with GPS and Gnoga is with'ed that GPS 2017 is crashing. In the log I have this:
 
> Are there other things I could try?

It looks like the problem is a "wild" pointer.  At a guess, it looks like during finalization a 32-bit value was treated as a 64-bit address. Oops!  I'd put a print command in the place where the failure is occurring. I assume you have a minimal program that causes the crash, since it seems to be occurring after the main program completes.

Re: Problem with GPS under MacOS

[Laurent]

On Tuesday, 22 August 2017 07:43:48 UTC+2, Robert Eachus  wrote:
> On Thursday, August 17, 2017 at 4:48:02 PM UTC-4, Laurent wrote:
> > Hi
> > 
> > I have the problem that when I work with GPS and Gnoga is with'ed that GPS 2017 is crashing. In the log I have this:
>  
> > Are there other things I could try?
> 
> It looks like the problem is a "wild" pointer.  At a guess, it looks like during finalization a 32-bit value was >treated as a 64-bit address. Oops!  I'd put a print command in the place where the failure is occurring. I >assume you have a minimal program that causes the crash, since it seems to be occurring after the main >program completes.

It is actually GPS itself crashing. Don't need to touch compile, build or something else. Just trying to type a word in the editor. So putting a print command won't help as nothing of my program is compiled or executed. Or you have a crystal ball?

The only pointer GPS could have a problem with are those in the handles provided by simple components in the gnoga library.  As I am apparently the only one having this problem I suppose that GPS has I problem with what I try to do. 

GPS is a better text editor so I don't get what the problem could be. 

The difference in behaviour between GPS 2016 (BOD) and 2017(CDT) is also confusing. I suppose that some of Apple's system protection measures are to blame too. GPS 2016 is tolerated and hangs forever. I have a quad core, so 3 cores to go. 2017 is suspicious and gets killed.

Not really motivated to play a match of ping pong between Apple and Adacore with myself as ball.

Will send the crashlog to Adacore but I don't expect something useful.

More out of despair than actually hoping that it would change something, I tried to open my project on my old Mini Mac. Has 2GB RAM and the latest Mac OS which can be installed is 10.7.5. The latest gnat which works is 2013. 

Ok GPS uses X11 and is ugly as hell but no crash, no BOD. Made the changes I wanted to try. Plugged the USB stick back to my main desktop and no more crash!?

WTF? No idea what, why and where the problem is.

I tried to deactivate the autocomplete in GPS. No change. Don't know how the feature is called when you type the name of an "object.", package or type and GPS shows the different possibilities available.

Thought that it could be that one somehow chasing its own tail.

Thanks

Laurent

Re: Problem with GPS under MacOS

[Simon Wright]

Laurent <lutgenl@icloud.com> writes:

> WTF? No idea what, why and where the problem is.

Just possibly it's something corrupt in your ~/.gps/? Maybe one of the
log files in there would help. Sometimes people recommend wiping the
directory and starting over.

Re: Problem with GPS under MacOS

[Simon Wright]

I should add, I tried building/editing tutorial_01 just now, no
problem. GNAT GPL 2017, macOS 10.12.6.

Re: Problem with GPS under MacOS

[Laurent]

On Tuesday, 22 August 2017 21:43:43 UTC+2, Simon Wright  wrote:
> 
> > WTF? No idea what, why and where the problem is.
> 
> Just possibly it's something corrupt in your ~/.gps/? Maybe one of the
> log files in there would help. Sometimes people recommend wiping the
> directory and starting over.

When I contacted Adacore the first time they recommended that too but it didn't last very long.

Corrupt GPS folder on 2 different macs. Strange coincidence.

The actual version of my project is stable (fingers crossed). Had a backup of a previous one, loaded into GPS and CDT. Ok trying to make a minimal test from it. Hm no crash. Back to the backup, which now doesn't crash either? I have only tried on my main desktop. Should probably try on my macbook with macos 10.12. Tomorrow

Bah I think I have gremlins...

This time the crashlog is slightly different:
----------------------------------------
Process:               gps_exe [1549]
Path:                  /usr/local/gnat/bin/gps_exe
Identifier:            com.adacore
Version:               6.0.1 (6.0.1)
Code Type:             X86-64 (Native)
Parent Process:        ??? [1]
Responsible:           gps_exe [1549]
User ID:               501

Date/Time:             2017-08-22 22:29:29.735 +0200
OS Version:            Mac OS X 10.11.6 (15G1611)
Report Version:        11
Anonymous UUID:        5A0FB384-243D-4BD4-E463-DF298380860D


Time Awake Since Boot: 8200 seconds

System Integrity Protection: enabled

Crashed Thread:        0  Dispatch queue: com.apple.main-thread

Exception Type:        EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:       KERN_PROTECTION_FAILURE at 0x00007fff5f3ffff0
Exception Note:        EXC_CORPSE_NOTIFY

VM Regions Near 0x7fff5f3ffff0:
    Stack                  00007000010f1000-0000700001173000 [  520K] rw-/rwx SM=COW  thread 11
--> STACK GUARD            00007fff5bc00000-00007fff5f400000 [ 56.0M] ---/rwx SM=NUL  stack guard for thread 0
    Stack                  00007fff5f400000-00007fff5fbe7000 [ 8092K] rw-/rwx SM=COW  thread 0

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   gps_exe                       	0x00000001004487b1 ada_semantic_tree__get_name__2 + 17
1   gps_exe                       	0x00000001004750b5 ada_semantic_tree__declarations__find_declarations__analyze_token.10531 + 1013

Thanks

Re: Problem with GPS under MacOS

[Anh Vo]

On Tuesday, August 22, 2017 at 2:04:30 PM UTC-7, Laurent wrote:
> On Tuesday, 22 August 2017 21:43:43 UTC+2, Simon Wright  wrote:
> > 

<< This time the crashlog is slightly different: 
---------------------------------------- 
Process:               gps_exe [1549] 
Path:                  /usr/local/gnat/bin/gps_exe 
Identifier:            com.adacore 
Version:               6.0.1 (6.0.1) 
Code Type:             X86-64 (Native) 
Parent Process:        ??? [1] 
Responsible:           gps_exe [1549] 
User ID:               501  >>

I am curious why GPS version 6.0.1 recorded in the log file while GPS 2017 was used. Is it possible that your GPS 2016 still visible some how. By the way, I have almost zero knowledge of Mac OS.

Anh Vo

Re: Problem with GPS under MacOS

[Laurent]

On Wednesday, 23 August 2017 22:13:41 UTC+2, Anh Vo  wrote:
> On Tuesday, August 22, 2017 at 2:04:30 PM UTC-7, Laurent wrote:
> > On Tuesday, 22 August 2017 21:43:43 UTC+2, Simon Wright  wrote:
> > > 
> 
> << This time the crashlog is slightly different: 
> ---------------------------------------- 
> Process:               gps_exe [1549] 
> Path:                  /usr/local/gnat/bin/gps_exe 
> Identifier:            com.adacore 
> Version:               6.0.1 (6.0.1) 
> Code Type:             X86-64 (Native) 
> Parent Process:        ??? [1] 
> Responsible:           gps_exe [1549] 
> User ID:               501  >>
> 
> I am curious why GPS version 6.0.1 recorded in the log file while GPS 2017 was used. Is it possible that your GPS 2016 still visible some how. By the way, I have almost zero knowledge of Mac OS.
> 
> Anh Vo

With gnat 2017 installed, from the about menu of GPS:

GPS 2017 (20170515) hosted on x86_64-apple-darwin14.5.0
GNAT GPL 2017 (20170515-63)

the GNAT Programming Studio

(c) 2001-2017 AdaCore

GPS 2016 is hanging and doesn't produce a system crash log at all. Perhaps it has been forgotten to change the version in the 2017 one?

Re: Problem with GPS under MacOS

[Laurent]

On Tuesday, 22 August 2017 21:43:43 UTC+2, Simon Wright  wrote:
> Maybe one of the
> log files in there would help. 

quite practical that those log files have a timestamp but no date.

Found in some of them at the end this. I hope that it will be readable, otherwise I have to upload the files somewhere. 
-----------------------------
GPS 2016:

[EDITOR_VIEW] 104/2613 Build_Editor_Context (18:24:36.235)
[COMPLETION.EXCEPTIONS] 13/4049 Unexpected exception: raised STORAGE_ERROR : stack overflow
_COMPLETION.EXCEPTIONS_ Load address: 0x100000000
_COMPLETION.EXCEPTIONS_ Call stack traceback locations:
_COMPLETION.EXCEPTIONS_ 0x101d0ded7 0x7fff939b3528 0x7fff8a54c4b0 0x7fff8a54febf 0x1004020cd 0x10040832a 0x10039845b 0x10039bb0e 0x100410d1f 0x10040f4a4 0x1004105f6 0x1003bcb6e 0x1003bf527 0x10039d9af 0x100406958 0x10039bbfd 0x1003dd3e0 0x1003ddcdb 0x1003dd116 0x10040f0c5 0x1003982f8 0x10039bb0e 0x100410d1f 0x10040f4a4 0x10040f53f 0x100410db1 0x10040f4a4 0x1004105f6 0x1003bcb6e 0x1003bce0d 0x1003bf527 0x10039d9af 0x100406958 0x10039bbfd 0x1003dd3e0 0x1003ddcdb 0x1003dd116 0x10040f0c5 0x1003982f8 0x10039bb0e 0x100410d1f 0x10040f4a4 0x10040f53f 0x100410db1 0x10040f4a4 0x1004105f6 0x1003bcb6e 0x1003bce0d 0x1003bf527 0x10039d9af (18:24:36.407)
[XREF] 111/4053 Find_Declaration of O file=base_types_analyses-antibiotics.adb project=Bci_V2 line= 37 col= 7 (18:24:36.513)
   [XREF] 112/4054 Searching entity declaration in constructs (18:24:36.517)
[EDITOR_VIEW] 105/4057 Build_Editor_Context (18:24:36.568)
[COMPLETION.EXCEPTIONS] 14/4058 Unexpected exception: raised CONSTRAINT_ERROR : erroneous memory access
_COMPLETION.EXCEPTIONS_ Load address: 0x100000000
_COMPLETION.EXCEPTIONS_ Call stack traceback locations:
_COMPLETION.EXCEPTIONS_ 0x101d0ded7 0x7fff939b3528 0x10054f68c 0x10055c611 0x10055c6a7 0x1007e5032 0x1007eccd0 0x1007da9aa 0x1075d11e8 0x1075d14b9 0x1075d1542 0x107100eaa 0x100023c78 0x101d7a631 (18:24:36.613)
[XREF] 113/4061 Find_Declaration of Ob file=base_types_analyses-antibiotics.adb project=Bci_V2 line= 37 col= 7 (18:24:36.776)
   [XREF] 114/4062 Searching entity declaration in constructs (18:24:36.777)
[EDITOR_VIEW] 106/4065 Build_Editor_Context (18:24:37.32)
[COMPLETION.EXCEPTIONS] 15/4066 Unexpected exception: raised CONSTRAINT_ERROR : erroneous memory access
_COMPLETION.EXCEPTIONS_ Load address: 0x100000000
_COMPLETION.EXCEPTIONS_ Call stack traceback locations:
_COMPLETION.EXCEPTIONS_ 0x101d0ded7 0x7fff939b3528 0x10054f68c 0x10055c611 0x10055c6a7 0x1007e5032 0x1007eccd0 0x1007da9aa 0x1075d11e8 0x1075d14b9 0x1075d1542 0x107100eaa 0x100023c78 0x101d7a631 (18:24:37.76)
[TOOLTIPS] 28/4068 Set_Tip_Area 195 429 7 13 (18:24:37.110)
[EDITOR_VIEW] 107/4069 Build_Editor_Context (18:24:37.110)
[EDITOR.TOOLTIPS] 10/4070 Tooltip on  (18:24:37.110)
[TOOLTIPS] 29/4071 No tooltip to display at this location (18:24:37.110)
[EDITOR_VIEW] 108/4073 Build_Editor_Context (18:24:37.216)
[COMPLETION.EXCEPTIONS] 16/4074 Unexpected exception: raised CONSTRAINT_ERROR : erroneous memory access
_COMPLETION.EXCEPTIONS_ Load address: 0x100000000
_COMPLETION.EXCEPTIONS_ Call stack traceback locations:
_COMPLETION.EXCEPTIONS_ 0x101d0ded7 0x7fff939b3528 0x10054f68c 0x10055c611 0x10055c6a7 0x1007e5032 0x1007eccd0 0x1007da9aa 0x1075d11e8 0x1075d14b9 0x1075d1542 0x107100eaa 0x100023c78 0x101d7a631 (18:24:37.264)
[XREF] 115/4077 Find_Declaration of Obje file=base_types_analyses-antibiotics.adb project=Bci_V2 line= 37 col= 7 (18:24:37.464)
   [XREF] 116/4078 Searching entity declaration in constructs (18:24:37.465)
[EDITOR_VIEW] 109/4081 Build_Editor_Context (18:24:37.688)
[COMPLETION.EXCEPTIONS] 17/4082 Unexpected exception: raised CONSTRAINT_ERROR : erroneous memory access
_COMPLETION.EXCEPTIONS_ Load address: 0x100000000
_COMPLETION.EXCEPTIONS_ Call stack traceback locations:
_COMPLETION.EXCEPTIONS_ 0x101d0ded7 0x7fff939b3528 0x10054f68c 0x10055c611 0x10055c6a7 0x1007e5032 0x1007eccd0 0x1007da9aa 0x1075d11e8 0x1075d14b9 0x1075d1542 0x107100eaa 0x100023c78 0x101d7a631 (18:24:37.732)
[EDITOR_VIEW] 110/4085 Build_Editor_Context (18:24:37.784)
[COMPLETION.EXCEPTIONS] 18/4086 Unexpected exception: raised CONSTRAINT_ERROR : erroneous memory access
_COMPLETION.EXCEPTIONS_ Load address: 0x100000000
_COMPLETION.EXCEPTIONS_ Call stack traceback locations:
_COMPLETION.EXCEPTIONS_ 0x101d0ded7 0x7fff939b3528 0x10054f68c 0x10055c611 0x10055c6a7 0x1007e5032 0x1007eccd0 0x1007da9aa 0x1075d11e8 0x1075d14b9 0x1075d1542 0x107100eaa 0x100023c78 0x101d7a631 (18:24:37.833)
[XREF] 117/4089 Find_Declaration of Object file=base_types_analyses-antibiotics.adb project=Bci_V2 line= 37 col= 7 (18:24:38.36)
   [XREF] 118/4090 Searching entity declaration in constructs (18:24:38.37)
[XREF] 119/4092 Get_Body of Object fuzzy=TRUE (18:24:38.38)
   [XREF] 120/4093 Body computed from constructs at base_types_analyses-antibiotics.ads:36:9 (18:24:38.38)
   [XREF] 121/4094 Use body from constructs (18:24:38.38)
[EDITOR_VIEW] 111/4096 Build_Editor_Context (18:24:39.736)
[EDITOR_VIEW] 112/4097 Build_Editor_Context (18:24:39.753)
---------------------------
With GPS 2017:

[EDITOR_VIEW] Build_Editor_Context (22:51:02.239)
[COMPLETION.EXCEPTIONS] Unexpected exception: raised CONSTRAINT_ERROR : ada_semantic_tree-type_tree.adb:533:31 access check failed
_COMPLETION.EXCEPTIONS_ Load address: 0x100000000
_COMPLETION.EXCEPTIONS_ Call stack traceback locations:
_COMPLETION.EXCEPTIONS_ 0x1004d82e2 0x1004d8621 0x100454388 0x10046e084 0x10044814b 0x10046a532 0x10046ae42 0x10046a8b3 0x10046a2d6 0x100474b82 0x100443f3b 0x10044804e 0x10046464a 0x100464a71 0x10046e14f 0x10044814b 0x100697f06 0x10067e7b8 0x10068b7f8 0x100d5393f 0x100d59ddc 0x100d48fca 0x10ac631f8 0x10ac634c9 0x10ac63552 0x10a792eba 0x100022d56 0x101818801 (22:51:02.335)
[EDITOR_VIEW] Build_Editor_Context (22:51:03.381)
[COMPLETION.EXCEPTIONS] Unexpected exception: raised CONSTRAINT_ERROR : completion-ada-constructs_extractor.adb:365:30 access check failed
_COMPLETION.EXCEPTIONS_ Load address: 0x100000000
_COMPLETION.EXCEPTIONS_ Call stack traceback locations:
_COMPLETION.EXCEPTIONS_ 0x10069cdfc 0x100d3ea02 0x100d52d3d 0x100d59ddc 0x100d48fca 0x10ac631f8 0x10ac634c9 0x10ac63552 0x10a792eba 0x100022d56 0x101818801 (22:51:03.399)
[EDITOR_VIEW] Build_Editor_Context (22:51:03.581)
[COMPLETION.EXCEPTIONS] Unexpected exception: raised CONSTRAINT_ERROR : completion-ada-constructs_extractor.adb:365:30 access check failed
_COMPLETION.EXCEPTIONS_ Load address: 0x100000000
_COMPLETION.EXCEPTIONS_ Call stack traceback locations:
_COMPLETION.EXCEPTIONS_ 0x10069cdfc 0x100d3ea02 0x100d52d3d 0x100d59ddc 0x100d48fca 0x10ac631f8 0x10ac634c9 0x10ac63552 0x10a792eba 0x100022d56 0x101818801 (22:51:03.594)
[XREF] Find_Declaration of De file=base_types.ads project=Test line= 3 col= 27 (22:51:03.791)
   [XREF] Searching entity declaration in constructs (22:51:03.792)
[ACTIONS] Could not execute "Move to next line' (22:51:06.397)
[XREF] Find_Declaration of Deposit_Handles file=deposit_handles.ads project=default line= 31 col= 9 (22:51:06.425)
[LANGUAGE.TREE.DATABASE] File's tree is already up-to-date: /Volumes/Kingston/GPS/Library/xnadalib-2016/include/components/lib_components/deposit_handles.ads (22:51:06.425)
[LANGUAGE.TREE.DATABASE] File's tree is already up-to-date: /Volumes/Kingston/GPS/Library/xnadalib-2016/include/components/lib_components/deposit_handles.ads (22:51:06.425)
[COMPLETION.EXCEPTIONS] Unexpected exception: raised CONSTRAINT_ERROR : completion-ada-constructs_extractor.adb:365:30 access check failed
_COMPLETION.EXCEPTIONS_ Load address: 0x100000000
_COMPLETION.EXCEPTIONS_ Call stack traceback locations:
_COMPLETION.EXCEPTIONS_ 0x10069cdfc 0x100d3ea02 0x100d52d3d 0x100d59ddc 0x100d48fca 0x10ac631f8 0x10ac634c9 0x10ac63552 0x10a792eba 0x100022d56 0x101818801 (22:51:06.427)
[COMPLETION.EXCEPTIONS] Unexpected exception: raised CONSTRAINT_ERROR : completion-ada-constructs_extractor.adb:365:30 access check failed
_COMPLETION.EXCEPTIONS_ Load address: 0x100000000
_COMPLETION.EXCEPTIONS_ Call stack traceback locations:
_COMPLETION.EXCEPTIONS_ 0x10069cdfc 0x100d3ea02 0x100d52d3d 0x100d59ddc 0x100d48fca 0x10ac631f8 0x10ac634c9 0x10ac63552 0x10a792eba 0x100022d56 0x101818801 (22:51:06.445)
[ACTIONS] Could not execute "Python Auto Indentation' (22:51:08.205)
-------------------------------------------

Looks like my suspicion about the autocomplete wasn't so wrong?

Re: Problem with GPS under MacOS

[Simon Wright]

Laurent <lutgenl@icloud.com> writes:

> On Tuesday, 22 August 2017 21:43:43 UTC+2, Simon Wright  wrote:
>> Maybe one of the
>> log files in there would help. 
>
> quite practical that those log files have a timestamp but no date.
>
> Found in some of them at the end this. I hope that it will be
> readable, otherwise I have to upload the files somewhere.

There are quite a few exception tracebacks in those (surprisingly many,
really). You can decode them, to an extent (gps_exe is supplied without
full debug information, so not very helpful at first glance: for
example, for the first 2017 one,

$ atos -o /opt/gnat-gpl-2017/bin/gps_exe -l 0x100000000 0x1004d82e2 0x1004d8621 0x100454388 0x10046e084 0x10044814b 0x10046a532 0x10046ae42 0x10046a8b3 0x10046a2d6 0x100474b82 0x100443f3b 0x10044804e 0x10046464a 0x100464a71 0x10046e14f 0x10044814b 0x100697f06 0x10067e7b8 0x10068b7f8 0x100d5393f 0x100d59ddc 0x100d48fca 0x10ac631f8 0x10ac634c9 0x10ac63552 0x10a792eba 0x100022d56 0x101818801
ada_semantic_tree__type_tree__perform_type_analyzis_if_needed (in gps_exe) + 9362
ada_semantic_tree__type_tree__get_ada_type (in gps_exe) + 145
ada_semantic_tree__list_resolver__get_list_profile (in gps_exe) + 1752
ada_semantic_tree__declarations__configure_view__2 (in gps_exe) + 212
ada_semantic_tree__get_view (in gps_exe) + 91
ada_semantic_tree__entity_iteration__next__next_referenced_entity__set_sub_it.7143 (in gps_exe) + 162
ada_semantic_tree__entity_iteration__next__next_referenced_entity.7126 (in gps_exe) + 1314
ada_semantic_tree__entity_iteration__next (in gps_exe) + 163
ada_semantic_tree__entity_iteration__to_semantic_tree_iterator (in gps_exe) + 3078
ada_semantic_tree__declarations__first__4 (in gps_exe) + 802
ada_semantic_tree__entity_list_pckg__first__2 (in gps_exe) + 91
ada_semantic_tree__first (in gps_exe) + 78
ada_semantic_tree__generics__get_generic_entity__2 (in gps_exe) + 1450
ada_semantic_tree__generics__make_generic_instance (in gps_exe) + 65
ada_semantic_tree__declarations__configure_view__2 (in gps_exe) + 415
ada_semantic_tree__get_view (in gps_exe) + 91
completion__ada__constructs_extractor__next__2 (in gps_exe) + 614
completion__completion_list_pckg__next__2 (in gps_exe) + 56
completion__next__2 (in gps_exe) + 88
completion_window__idle_expand (in gps_exe) + 4559
completion_window__idle_compute (in gps_exe) + 140
completion_window__completion_explorer_idle__general_cb (in gps_exe) + 42
0x10ac631f8
0x10ac634c9
0x10ac63552
0x10a792eba
_ada_gps__main (in gps_exe) + 13494
main (in gps_exe) + 65


On thinking about it, though, the one that crashed the program probably
wouldn't have made it into the log file. To find the problem one would
need to rebuild GPS with debug on. Personally I find there are just too
many dependencies, and I don't use GPS enough to go to the trouble.

Re: Problem with GPS under MacOS

[Laurent]

On Wednesday, 23 August 2017 08:56:05 UTC+2, Simon Wright  wrote:

> There are quite a few exception tracebacks in those (surprisingly many,
> really). You can decode them, to an extent (gps_exe is supplied without
> full debug information, so not very helpful at first glance: for
> example, for the first 2017 one,

At least it proves that there is a problem.

> 
> On thinking about it, though, the one that crashed the program probably
> wouldn't have made it into the log file. To find the problem one would
> need to rebuild GPS with debug on. Personally I find there are just too
> many dependencies, and I don't use GPS enough to go to the trouble.

A few years ago I tried to build it from source following a guide from someone in this group. I got half through before I stumbled on a problem I couldn't solve. The guide is still available but  I doubt that it would work this time.

I am used to GPS and until now I didn't have any crippling problem. Don't think that I would switch to emacs or Eclipse.

For the moment GPS behaves and I don't see a reason for opening a second building site.

I will send the logs to Adacore to see what they say. Would actually be their job to figure out why their program doesn't work.

Quite amazed how much Python is used in GPS. Apart laziness, is there an other reason? 

Thanks

Laurent