Discussion:
Upgrading 32-bit Mac apps to 64-bit
Paul Young
2017-05-20 16:00:45 UTC
Permalink
I am using a MacBook Pro running macOS Sierra Version 10.12.4 to upgrade my first six 32-bits Mac apps to 64-bits.

Each of the six apps worked fine when compiled for 32-bits.

Because my Mac Xojo license expired late last year, I used Xojo 2017 Release 1.1 to test the apps in the IDE for 64-bits and then compiled them for 64-bits using Xojo 2016 Release 3.

Launching each app twenty times, I recorded an exception upon close 20% to 50% of the time.

The Console log shows: “Service exited dur to signal: Segmentation fault: 11 sent by exc handler (0).

Can someone tell me in simple English what this means?

Thanks in advance.

Paul Young, CSoM
________________________________
Jon Ogden
2017-05-20 17:01:30 UTC
Permalink
You have something in your code that is not truly 64 bit compatible. Maybe you are using a 32 bit integer some place where you should be using 64 bit.

There's not much that one can tell from that. But it looks to me like some object isn't closing correctly.

You don't have to do much to make 64 bit work. But you do have to adjust some things.

I would try stepping through the code when closing your app to find the thing causing the problem. It has likely always been there but Xojo and the 32 bit framework was a little more forgiving.

Sent from my iPhone
Post by Paul Young
I am using a MacBook Pro running macOS Sierra Version 10.12.4 to upgrade my first six 32-bits Mac apps to 64-bits.
Each of the six apps worked fine when compiled for 32-bits.
Because my Mac Xojo license expired late last year, I used Xojo 2017 Release 1.1 to test the apps in the IDE for 64-bits and then compiled them for 64-bits using Xojo 2016 Release 3.
Launching each app twenty times, I recorded an exception upon close 20% to 50% of the time.
The Console log shows: “Service exited dur to signal: Segmentation fault: 11 sent by exc handler (0).
Can someone tell me in simple English what this means?
Thanks in advance.
Paul Young, CSoM
_______________________________________________
https://forum.xojo.com/
_______________________________________________

Xojo forum:
Jon Ogden
2017-05-20 17:09:30 UTC
Permalink
Thinking about this further, this is my educated guess.

The 32 bit framework shut things down in a certain order and you relied on that in your code to close out all your objects. The 64 bit framework is handling all that differently so the order you relied on before is now different. So some object is calling on or relying on some other object that is already closed. When that happens things crash.

You'll just have to step through things to figure it out. Don't rely on the framework doing things in a specific order.

Sent from my iPhone
Post by Jon Ogden
You have something in your code that is not truly 64 bit compatible. Maybe you are using a 32 bit integer some place where you should be using 64 bit.
There's not much that one can tell from that. But it looks to me like some object isn't closing correctly.
You don't have to do much to make 64 bit work. But you do have to adjust some things.
I would try stepping through the code when closing your app to find the thing causing the problem. It has likely always been there but Xojo and the 32 bit framework was a little more forgiving.
Sent from my iPhone
Post by Paul Young
I am using a MacBook Pro running macOS Sierra Version 10.12.4 to upgrade my first six 32-bits Mac apps to 64-bits.
Each of the six apps worked fine when compiled for 32-bits.
Because my Mac Xojo license expired late last year, I used Xojo 2017 Release 1.1 to test the apps in the IDE for 64-bits and then compiled them for 64-bits using Xojo 2016 Release 3.
Launching each app twenty times, I recorded an exception upon close 20% to 50% of the time.
The Console log shows: “Service exited dur to signal: Segmentation fault: 11 sent by exc handler (0).
Can someone tell me in simple English what this means?
Thanks in advance.
Paul Young, CSoM
_______________________________________________
https://forum.xojo.com/
_______________________________________________
https://forum.xojo.com/
___________________________________________
Paul Young
2017-05-20 18:04:03 UTC
Permalink
Thanks, Jon.

Appreciate your input.

Paul Young, CSoM
Post by Jon Ogden
Thinking about this further, this is my educated guess.
The 32 bit framework shut things down in a certain order and you relied on that in your code to close out all your objects. The 64 bit framework is handling all that differently so the order you relied on before is now different. So some object is calling on or relying on some other object that is already closed. When that happens things crash.
You'll just have to step through things to figure it out. Don't rely on the framework doing things in a specific order.
Sent from my iPhone
Post by Jon Ogden
You have something in your code that is not truly 64 bit compatible. Maybe you are using a 32 bit integer some place where you should be using 64 bit.
There's not much that one can tell from that. But it looks to me like some object isn't closing correctly.
You don't have to do much to make 64 bit work. But you do have to adjust some things.
I would try stepping through the code when closing your app to find the thing causing the problem. It has likely always been there but Xojo and the 32 bit framework was a little more forgiving.
Sent from my iPhone
Post by Paul Young
I am using a MacBook Pro running macOS Sierra Version 10.12.4 to upgrade my first six 32-bits Mac apps to 64-bits.
Each of the six apps worked fine when compiled for 32-bits.
Because my Mac Xojo license expired late last year, I used Xojo 2017 Release 1.1 to test the apps in the IDE for 64-bits and then compiled them for 64-bits using Xojo 2016 Release 3.
Launching each app twenty times, I recorded an exception upon close 20% to 50% of the time.
The Console log shows: “Service exited dur to signal: Segmentation fault: 11 sent by exc handler (0).
Can someone tell me in simple English what this means?
Thanks in advance.
Paul Young, CSoM
_______________________________________________

Xojo forum:

https:/
Paul Young
2017-05-21 18:59:06 UTC
Permalink
Nothing significant to report after:

a. making sure all integers are Int64

b. making sure all other Windows are closed before running the Window1.Close code

c. stopping the one timer that is running in Window1 (Timer1.Mode = 0)

d. stepping through the code (no problems until Window1 is closed and then, occasionally, an exception is thrown)

Is there an article available that summarizes changes to make to 32-bit code before compiling to 64-bit code?

Thanks in advance.

Paul Young, CSoM
Post by Jon Ogden
Thinking about this further, this is my educated guess.
The 32 bit framework shut things down in a certain order and you relied on that in your code to close out all your objects. The 64 bit framework is handling all that differently so the order you relied on before is now different. So some object is calling on or relying on some other object that is already closed. When that happens things crash.
You'll just have to step through things to figure it out. Don't rely on the framework doing things in a specific order.
Sent from my iPhone
Post by Jon Ogden
You have something in your code that is not truly 64 bit compatible. Maybe you are using a 32 bit integer some place where you should be using 64 bit.
There's not much that one can tell from that. But it looks to me like some object isn't closing correctly.
You don't have to do much to make 64 bit work. But you do have to adjust some things.
I would try stepping through the code when closing your app to find the thing causing the problem. It has likely always been there but Xojo and the 32 bit framework was a little more forgiving.
Sent from my iPhone
Post by Paul Young
I am using a MacBook Pro running macOS Sierra Version 10.12.4 to upgrade my first six 32-bits Mac apps to 64-bits.
Each of the six apps worked fine when compiled for 32-bits.
Because my Mac Xojo license expired late last year, I used Xojo 2017 Release 1.1 to test the apps in the IDE for 64-bits and then compiled them for 64-bits using Xojo 2016 Release 3.
Launching each app twenty times, I recorded an exception upon close 20% to 50% of the time.
The Console log shows: “Service exited dur to signal: Segmentation fault: 11 sent by exc handler (0).
Can someone tell me in simple English what this means?
Thanks in advance.
Paul Young, CSoM
_______________________________________________

Xojo forum:

https://forum.x
Jon Ogden
2017-05-21 19:07:16 UTC
Permalink
Paul,

You can always look in the docs. But there is something in an object of code that is in your window or app that is not closing before the app tries to close. Make sure you have no circular references and make sure that all of your things like AddHandler references are undone. Some reference to something is being left open.

Jon

Sent from my iPhone
Post by Paul Young
a. making sure all integers are Int64
b. making sure all other Windows are closed before running the Window1.Close code
c. stopping the one timer that is running in Window1 (Timer1.Mode = 0)
d. stepping through the code (no problems until Window1 is closed and then, occasionally, an exception is thrown)
Is there an article available that summarizes changes to make to 32-bit code before compiling to 64-bit code?
Thanks in advance.
Paul Young, CSoM
Post by Jon Ogden
Thinking about this further, this is my educated guess.
The 32 bit framework shut things down in a certain order and you relied on that in your code to close out all your objects. The 64 bit framework is handling all that differently so the order you relied on before is now different. So some object is calling on or relying on some other object that is already closed. When that happens things crash.
You'll just have to step through things to figure it out. Don't rely on the framework doing things in a specific order.
Sent from my iPhone
Post by Jon Ogden
You have something in your code that is not truly 64 bit compatible. Maybe you are using a 32 bit integer some place where you should be using 64 bit.
There's not much that one can tell from that. But it looks to me like some object isn't closing correctly.
You don't have to do much to make 64 bit work. But you do have to adjust some things.
I would try stepping through the code when closing your app to find the thing causing the problem. It has likely always been there but Xojo and the 32 bit framework was a little more forgiving.
Sent from my iPhone
Post by Paul Young
I am using a MacBook Pro running macOS Sierra Version 10.12.4 to upgrade my first six 32-bits Mac apps to 64-bits.
Each of the six apps worked fine when compiled for 32-bits.
Because my Mac Xojo license expired late last year, I used Xojo 2017 Release 1.1 to test the apps in the IDE for 64-bits and then compiled them for 64-bits using Xojo 2016 Release 3.
Launching each app twenty times, I recorded an exception upon close 20% to 50% of the time.
The Console log shows: “Service exited dur to signal: Segmentation fault: 11 sent by exc handler (0).
Can someone tell me in simple English what this means?
Thanks in advance.
Paul Young, CSoM
_______________________________________________
https://forum.xojo.com/
_______________________________________________

Xojo forum:

https://forum.xojo.co
Paul Young
2017-05-21 20:31:56 UTC
Permalink
Jon,

Would an instance of a method cause this? If so, how would one close/cancel/etc. the instance?

Paul
Post by Jon Ogden
Paul,
You can always look in the docs. But there is something in an object of code that is in your window or app that is not closing before the app tries to close. Make sure you have no circular references and make sure that all of your things like AddHandler references are undone. Some reference to something is being left open.
Jon
Sent from my iPhone
Post by Paul Young
a. making sure all integers are Int64
b. making sure all other Windows are closed before running the Window1.Close code
c. stopping the one timer that is running in Window1 (Timer1.Mode = 0)
d. stepping through the code (no problems until Window1 is closed and then, occasionally, an exception is thrown)
Is there an article available that summarizes changes to make to 32-bit code before compiling to 64-bit code?
Thanks in advance.
Paul Young, CSoM
Post by Jon Ogden
Thinking about this further, this is my educated guess.
The 32 bit framework shut things down in a certain order and you relied on that in your code to close out all your objects. The 64 bit framework is handling all that differently so the order you relied on before is now different. So some object is calling on or relying on some other object that is already closed. When that happens things crash.
You'll just have to step through things to figure it out. Don't rely on the framework doing things in a specific order.
Sent from my iPhone
Post by Jon Ogden
You have something in your code that is not truly 64 bit compatible. Maybe you are using a 32 bit integer some place where you should be using 64 bit.
There's not much that one can tell from that. But it looks to me like some object isn't closing correctly.
You don't have to do much to make 64 bit work. But you do have to adjust some things.
I would try stepping through the code when closing your app to find the thing causing the problem. It has likely always been there but Xojo and the 32 bit framework was a little more forgiving.
Sent from my iPhone
Post by Paul Young
I am using a MacBook Pro running macOS Sierra Version 10.12.4 to upgrade my first six 32-bits Mac apps to 64-bits.
Each of the six apps worked fine when compiled for 32-bits.
Because my Mac Xojo license expired late last year, I used Xojo 2017 Release 1.1 to test the apps in the IDE for 64-bits and then compiled them for 64-bits using Xojo 2016 Release 3.
Launching each app twenty times, I recorded an exception upon close 20% to 50% of the time.
The Console log shows: “Service exited dur to signal: Segmentation fault: 11 sent by exc handler (0).
Can someone tell me in simple English what this means?
Thanks in advance.
Paul Young, CSoM
________________________________________
Jon Ogden
2017-05-21 20:33:36 UTC
Permalink
Methods aren't objects. It's an instance of an object or some reference to an object.

Sent from my iPhone
Post by Paul Young
Jon,
Would an instance of a method cause this? If so, how would one close/cancel/etc. the instance?
Paul
Post by Jon Ogden
Paul,
You can always look in the docs. But there is something in an object of code that is in your window or app that is not closing before the app tries to close. Make sure you have no circular references and make sure that all of your things like AddHandler references are undone. Some reference to something is being left open.
Jon
Sent from my iPhone
Post by Paul Young
a. making sure all integers are Int64
b. making sure all other Windows are closed before running the Window1.Close code
c. stopping the one timer that is running in Window1 (Timer1.Mode = 0)
d. stepping through the code (no problems until Window1 is closed and then, occasionally, an exception is thrown)
Is there an article available that summarizes changes to make to 32-bit code before compiling to 64-bit code?
Thanks in advance.
Paul Young, CSoM
Post by Jon Ogden
Thinking about this further, this is my educated guess.
The 32 bit framework shut things down in a certain order and you relied on that in your code to close out all your objects. The 64 bit framework is handling all that differently so the order you relied on before is now different. So some object is calling on or relying on some other object that is already closed. When that happens things crash.
You'll just have to step through things to figure it out. Don't rely on the framework doing things in a specific order.
Sent from my iPhone
Post by Jon Ogden
You have something in your code that is not truly 64 bit compatible. Maybe you are using a 32 bit integer some place where you should be using 64 bit.
There's not much that one can tell from that. But it looks to me like some object isn't closing correctly.
You don't have to do much to make 64 bit work. But you do have to adjust some things.
I would try stepping through the code when closing your app to find the thing causing the problem. It has likely always been there but Xojo and the 32 bit framework was a little more forgiving.
Sent from my iPhone
Post by Paul Young
I am using a MacBook Pro running macOS Sierra Version 10.12.4 to upgrade my first six 32-bits Mac apps to 64-bits.
Each of the six apps worked fine when compiled for 32-bits.
Because my Mac Xojo license expired late last year, I used Xojo 2017 Release 1.1 to test the apps in the IDE for 64-bits and then compiled them for 64-bits using Xojo 2016 Release 3.
Launching each app twenty times, I recorded an exception upon close 20% to 50% of the time.
The Console log shows: “Service exited dur to signal: Segmentation fault: 11 sent by exc handler (0).
Can someone tell me in simple English what this means?
Thanks in advance.
Paul Young, CSoM
_______________________________________________
https://forum.xojo.com/
_______________________________________________

Xojo forum:

https:
Claudius Sailer
2017-05-21 20:47:02 UTC
Permalink
Hello,

I know it is painful, but when you can't find it, add MsgBox commands to your code. Than you can see until everything is fine and when it crashes.

MsgBox "Step 1"

MsgBox "Step 2"

and so on. So you can possibly find the problem easier.

I know that it is actually a problem that debug mode in 64Bit can't finished correctly.

Claudius
Post by Paul Young
Jon,
Would an instance of a method cause this? If so, how would one close/cancel/etc. the instance?
Paul
Post by Jon Ogden
Paul,
You can always look in the docs. But there is something in an object of code that is in your window or app that is not closing before the app tries to close. Make sure you have no circular references and make sure that all of your things like AddHandler references are undone. Some reference to something is being left open.
Jon
Sent from my iPhone
Post by Paul Young
a. making sure all integers are Int64
b. making sure all other Windows are closed before running the Window1.Close code
c. stopping the one timer that is running in Window1 (Timer1.Mode = 0)
d. stepping through the code (no problems until Window1 is closed and then, occasionally, an exception is thrown)
Is there an article available that summarizes changes to make to 32-bit code before compiling to 64-bit code?
Thanks in advance.
Paul Young, CSoM
Post by Jon Ogden
Thinking about this further, this is my educated guess.
The 32 bit framework shut things down in a certain order and you relied on that in your code to close out all your objects. The 64 bit framework is handling all that differently so the order you relied on before is now different. So some object is calling on or relying on some other object that is already closed. When that happens things crash.
You'll just have to step through things to figure it out. Don't rely on the framework doing things in a specific order.
Sent from my iPhone
Post by Jon Ogden
You have something in your code that is not truly 64 bit compatible. Maybe you are using a 32 bit integer some place where you should be using 64 bit.
There's not much that one can tell from that. But it looks to me like some object isn't closing correctly.
You don't have to do much to make 64 bit work. But you do have to adjust some things.
I would try stepping through the code when closing your app to find the thing causing the problem. It has likely always been there but Xojo and the 32 bit framework was a little more forgiving.
Sent from my iPhone
Post by Paul Young
I am using a MacBook Pro running macOS Sierra Version 10.12.4 to upgrade my first six 32-bits Mac apps to 64-bits.
Each of the six apps worked fine when compiled for 32-bits.
Because my Mac Xojo license expired late last year, I used Xojo 2017 Release 1.1 to test the apps in the IDE for 64-bits and then compiled them for 64-bits using Xojo 2016 Release 3.
Launching each app twenty times, I recorded an exception upon close 20% to 50% of the time.
The Console log shows: “Service exited dur to signal: Segmentation fault: 11 sent by exc handler (0).
Can someone tell me in simple English what this means?
Thanks in advance.
Paul Young, CSoM
_______________________________________________
https://forum.xojo.com/
_______________________________________________

Xojo forum:

h
Jon Ogden
2017-05-21 20:49:11 UTC
Permalink
MsgBox might not be the best thing as it interrupts the flow of events. What might be better are system.debuglog messages.

Also, I have no problem quitting my 64 bit apps from the debugger.

Sent from my iPhone
Post by Claudius Sailer
Hello,
I know it is painful, but when you can't find it, add MsgBox commands to your code. Than you can see until everything is fine and when it crashes.
MsgBox "Step 1"
MsgBox "Step 2"
and so on. So you can possibly find the problem easier.
I know that it is actually a problem that debug mode in 64Bit can't finished correctly.
Claudius
Post by Paul Young
Jon,
Would an instance of a method cause this? If so, how would one close/cancel/etc. the instance?
Paul
Post by Jon Ogden
Paul,
You can always look in the docs. But there is something in an object of code that is in your window or app that is not closing before the app tries to close. Make sure you have no circular references and make sure that all of your things like AddHandler references are undone. Some reference to something is being left open.
Jon
Sent from my iPhone
Post by Paul Young
a. making sure all integers are Int64
b. making sure all other Windows are closed before running the Window1.Close code
c. stopping the one timer that is running in Window1 (Timer1.Mode = 0)
d. stepping through the code (no problems until Window1 is closed and then, occasionally, an exception is thrown)
Is there an article available that summarizes changes to make to 32-bit code before compiling to 64-bit code?
Thanks in advance.
Paul Young, CSoM
Post by Jon Ogden
Thinking about this further, this is my educated guess.
The 32 bit framework shut things down in a certain order and you relied on that in your code to close out all your objects. The 64 bit framework is handling all that differently so the order you relied on before is now different. So some object is calling on or relying on some other object that is already closed. When that happens things crash.
You'll just have to step through things to figure it out. Don't rely on the framework doing things in a specific order.
Sent from my iPhone
Post by Jon Ogden
You have something in your code that is not truly 64 bit compatible. Maybe you are using a 32 bit integer some place where you should be using 64 bit.
There's not much that one can tell from that. But it looks to me like some object isn't closing correctly.
You don't have to do much to make 64 bit work. But you do have to adjust some things.
I would try stepping through the code when closing your app to find the thing causing the problem. It has likely always been there but Xojo and the 32 bit framework was a little more forgiving.
Sent from my iPhone
Post by Paul Young
I am using a MacBook Pro running macOS Sierra Version 10.12.4 to upgrade my first six 32-bits Mac apps to 64-bits.
Each of the six apps worked fine when compiled for 32-bits.
Because my Mac Xojo license expired late last year, I used Xojo 2017 Release 1.1 to test the apps in the IDE for 64-bits and then compiled them for 64-bits using Xojo 2016 Release 3.
Launching each app twenty times, I recorded an exception upon close 20% to 50% of the time.
The Console log shows: “Service exited dur to signal: Segmentation fault: 11 sent by exc handler (0).
Can someone tell me in simple English what this means?
Thanks in advance.
Paul Young, CSoM
_______________________________________________
https://forum.xojo.com/
_______________________________________________
https://forum.xojo.com/
_______________________________________________

Xojo forum:

htt
Claudius Sailer
2017-05-21 20:54:15 UTC
Permalink
all my 64Bit compiled Applications are running fine, but when I press Command-Q or select it in the Menu when I started them in debug mode no reaction. I have to kill it during Xojo.

Sorry I didn't know this "new" possibilities System.debuglog 🙈🙈🙈 thanks for this hint.
Post by Jon Ogden
MsgBox might not be the best thing as it interrupts the flow of events. What might be better are system.debuglog messages.
Also, I have no problem quitting my 64 bit apps from the debugger.
Sent from my iPhone
Post by Claudius Sailer
Hello,
I know it is painful, but when you can't find it, add MsgBox commands to your code. Than you can see until everything is fine and when it crashes.
MsgBox "Step 1"
MsgBox "Step 2"
and so on. So you can possibly find the problem easier.
I know that it is actually a problem that debug mode in 64Bit can't finished correctly.
Claudius
Post by Paul Young
Jon,
Would an instance of a method cause this? If so, how would one close/cancel/etc. the instance?
Paul
Post by Jon Ogden
Paul,
You can always look in the docs. But there is something in an object of code that is in your window or app that is not closing before the app tries to close. Make sure you have no circular references and make sure that all of your things like AddHandler references are undone. Some reference to something is being left open.
Jon
Sent from my iPhone
Post by Paul Young
a. making sure all integers are Int64
b. making sure all other Windows are closed before running the Window1.Close code
c. stopping the one timer that is running in Window1 (Timer1.Mode = 0)
d. stepping through the code (no problems until Window1 is closed and then, occasionally, an exception is thrown)
Is there an article available that summarizes changes to make to 32-bit code before compiling to 64-bit code?
Thanks in advance.
Paul Young, CSoM
Post by Jon Ogden
Thinking about this further, this is my educated guess.
The 32 bit framework shut things down in a certain order and you relied on that in your code to close out all your objects. The 64 bit framework is handling all that differently so the order you relied on before is now different. So some object is calling on or relying on some other object that is already closed. When that happens things crash.
You'll just have to step through things to figure it out. Don't rely on the framework doing things in a specific order.
Sent from my iPhone
Post by Jon Ogden
You have something in your code that is not truly 64 bit compatible. Maybe you are using a 32 bit integer some place where you should be using 64 bit.
There's not much that one can tell from that. But it looks to me like some object isn't closing correctly.
You don't have to do much to make 64 bit work. But you do have to adjust some things.
I would try stepping through the code when closing your app to find the thing causing the problem. It has likely always been there but Xojo and the 32 bit framework was a little more forgiving.
Sent from my iPhone
Post by Paul Young
I am using a MacBook Pro running macOS Sierra Version 10.12.4 to upgrade my first six 32-bits Mac apps to 64-bits.
Each of the six apps worked fine when compiled for 32-bits.
Because my Mac Xojo license expired late last year, I used Xojo 2017 Release 1.1 to test the apps in the IDE for 64-bits and then compiled them for 64-bits using Xojo 2016 Release 3.
Launching each app twenty times, I recorded an exception upon close 20% to 50% of the time.
The Console log shows: “Service exited dur to signal: Segmentation fault: 11 sent by exc handler (0).
Can someone tell me in simple English what this means?
Thanks in advance.
Paul Young, CSoM
_______________________________________________
https://forum.xojo.com/
_______________________________________________
https://forum.xojo.com/
_______________________________________________
https://forum.xojo.com/
_______________________________________________

Xojo forum:

http
Jon Ogden
2017-05-21 21:48:33 UTC
Permalink
Sounds like you don't have code to quit in your
Menu handler.

Sent from my iPhone
Post by Claudius Sailer
all my 64Bit compiled Applications are running fine, but when I press Command-Q or select it in the Menu when I started them in debug mode no reaction. I have to kill it during Xojo.
Sorry I didn't know this "new" possibilities System.debuglog 🙈🙈🙈 thanks for this hint.
Post by Jon Ogden
MsgBox might not be the best thing as it interrupts the flow of events. What might be better are system.debuglog messages.
Also, I have no problem quitting my 64 bit apps from the debugger.
Sent from my iPhone
Post by Claudius Sailer
Hello,
I know it is painful, but when you can't find it, add MsgBox commands to your code. Than you can see until everything is fine and when it crashes.
MsgBox "Step 1"
MsgBox "Step 2"
and so on. So you can possibly find the problem easier.
I know that it is actually a problem that debug mode in 64Bit can't finished correctly.
Claudius
Post by Paul Young
Jon,
Would an instance of a method cause this? If so, how would one close/cancel/etc. the instance?
Paul
Post by Jon Ogden
Paul,
You can always look in the docs. But there is something in an object of code that is in your window or app that is not closing before the app tries to close. Make sure you have no circular references and make sure that all of your things like AddHandler references are undone. Some reference to something is being left open.
Jon
Sent from my iPhone
Post by Paul Young
a. making sure all integers are Int64
b. making sure all other Windows are closed before running the Window1.Close code
c. stopping the one timer that is running in Window1 (Timer1.Mode = 0)
d. stepping through the code (no problems until Window1 is closed and then, occasionally, an exception is thrown)
Is there an article available that summarizes changes to make to 32-bit code before compiling to 64-bit code?
Thanks in advance.
Paul Young, CSoM
Post by Jon Ogden
Thinking about this further, this is my educated guess.
The 32 bit framework shut things down in a certain order and you relied on that in your code to close out all your objects. The 64 bit framework is handling all that differently so the order you relied on before is now different. So some object is calling on or relying on some other object that is already closed. When that happens things crash.
You'll just have to step through things to figure it out. Don't rely on the framework doing things in a specific order.
Sent from my iPhone
Post by Jon Ogden
You have something in your code that is not truly 64 bit compatible. Maybe you are using a 32 bit integer some place where you should be using 64 bit.
There's not much that one can tell from that. But it looks to me like some object isn't closing correctly.
You don't have to do much to make 64 bit work. But you do have to adjust some things.
I would try stepping through the code when closing your app to find the thing causing the problem. It has likely always been there but Xojo and the 32 bit framework was a little more forgiving.
Sent from my iPhone
Post by Paul Young
I am using a MacBook Pro running macOS Sierra Version 10.12.4 to upgrade my first six 32-bits Mac apps to 64-bits.
Each of the six apps worked fine when compiled for 32-bits.
Because my Mac Xojo license expired late last year, I used Xojo 2017 Release 1.1 to test the apps in the IDE for 64-bits and then compiled them for 64-bits using Xojo 2016 Release 3.
Launching each app twenty times, I recorded an exception upon close 20% to 50% of the time.
The Console log shows: “Service exited dur to signal: Segmentation fault: 11 sent by exc handler (0).
Can someone tell me in simple English what this means?
Thanks in advance.
Paul Young, CSoM
_______________________________________________
https://forum.xojo.com/
_______________________________________________
https://forum.xojo.com/
_______________________________________________
https://forum.xojo.com/
_______________________________________________
https://forum.xojo.com/
_______________________________________________

Xojo forum:

ht
Paul Young
2017-05-24 16:29:18 UTC
Permalink
Jon,

Thank you for that information. Your explanation makes sense. I added code to close other windows in Window1.Close in case a User has the Help window (or other window) open and clicks the Window1 red close button.

This code was removed, the app compiled again for 64-bit and retested (clicking the red close button to close). I continue to see an exception at times so I must have other problems. Someone needs to write instructions on changes needed to be successful for compiling apps for 64-bit that worked correctly when compiled for 32-bit. Others must be having similar problems.

Paul Young, CSoM
Let me try to explain this further.
You tell your app to quit. The framework starts shutting everything down. But who knows what order it shuts the windows and closes everything. You cannot rely on a specific order of closing. Yet, that is what you are doing. Your Window1.close event is making sure Window2 let’s say is closed. But if Window2 is already gone that could be a problem. Even more of a problem is Window2 trying to report something back to Window1 after Window1 is already gone.
And if Window1 is strongly referenced in Window2 and vice versa, then you end up with a circular reference and the object never really gets destroyed - hence the crash. All sorts of stuff could be going on.
If you need to close other windows from your main window, then I would suggest doing it in the CancelClose event so you can control it a little bit more.
But I guarantee you that this is what is causing your problems.
Jon
Paul,
I see your problem.
The close event in a window should never be used to close other windows. You are trying to close or obtain information on a window that is already gone or something is still closing in that second window when the first window shuts down completely. That’s why you are getting your error.
Check for windows to be closed in the close event of the app never in the close event of other windows.
Jon
Thanks for your response, Tim, but Window1.Close just ensures that other windows are closed, followed by Quit.
Jon Ogden suggested other problems (below) that could create this issue but I have not found any of those.
Paul Young, CSoM
Check the Window’s .Close event.
Tim
I used the Xojo sale to buy another Mac license for Xojo for this year.
So, I am now debugging and compiling my test app in Xojo 2017 Release 1.1.
I have found nothing that I recognize would cause an exception when I click the Red Close button on Window1. I added a Menu Handler for File \ Quit in the App area with Quit as the code. I can step through the code without seeing an exception until I click on the Red Close button on Window1. At that point, the app closes and frequently an exception is thrown.
When compiled for 64-bits, using File \ Quit now quits the app 100% of the time (run of 20 launches) without throwing an exception but closing the app using the Red Close button of Window1 throws an exception about 50% of the time.
Does this suggest anything new to anyone?
Paul Young, CSoM
good idea....
I had a FileQuit in the MenuHandler without code. I deleted it, now it works in Debug and in compiled version.
I thought I need this MenuHandler also without code 🙈🙈🙈
Post by Jon Ogden
Sounds like you don't have code to quit in your
Menu handler.
Sent from my iPhone
Post by Claudius Sailer
all my 64Bit compiled Applications are running fine, but when I press Command-Q or select it in the Menu when I started them in debug mode no reaction. I have to kill it during Xojo.
Sorry I didn't know this "new" possibilities System.debuglog 🙈🙈🙈 thanks for this hint.
Post by Jon Ogden
MsgBox might not be the best thing as it interrupts the flow of events. What might be better are system.debuglog messages.
Also, I have no problem quitting my 64 bit apps from the debugger.
Sent from my iPhone
Post by Claudius Sailer
Hello,
I know it is painful, but when you can't find it, add MsgBox commands to your code. Than you can see until everything is fine and when it crashes.
MsgBox "Step 1"
MsgBox "Step 2"
and so on. So you can possibly find the problem easier.
I know that it is actually a problem that debug mode in 64Bit can't finished correctly.
Claudius
Post by Paul Young
Jon,
Would an instance of a method cause this? If so, how would one close/cancel/etc. the instance?
Paul
Post by Jon Ogden
Paul,
You can always look in the docs. But there is something in an object of code that is in your window or app that is not closing before the app tries to close. Make sure you have no circular references and make sure that all of your things like AddHandler references are undone. Some reference to something is being left open.
Jon
Sent from my iPhone
Post by Paul Young
a. making sure all integers are Int64
b. making sure all other Windows are closed before running the Window1.Close code
c. stopping the one timer that is running in Window1 (Timer1.Mode = 0)
d. stepping through the code (no problems until Window1 is closed and then, occasionally, an exception is thrown)
Is there an article available that summarizes changes to make to 32-bit code before compiling to 64-bit code?
Thanks in advance.
Paul Young, CSoM
Post by Jon Ogden
Thinking about this further, this is my educated guess.
The 32 bit framework shut things down in a certain order and you relied on that in your code to close out all your objects. The 64 bit framework is handling all that differently so the order you relied on before is now different. So some object is calling on or relying on some other object that is already closed. When that happens things crash.
You'll just have to step through things to figure it out. Don't rely on the framework doing things in a specific order.
Sent from my iPhone
Post by Jon Ogden
You have something in your code that is not truly 64 bit compatible. Maybe you are using a 32 bit integer some place where you should be using 64 bit.
There's not much that one can tell from that. But it looks to me like some object isn't closing correctly.
You don't have to do much to make 64 bit work. But you do have to adjust some things.
I would try stepping through the code when closing your app to find the thing causing the problem. It has likely always been there but Xojo and the 32 bit framework was a little more forgiving.
Sent from my iPhone
Post by Paul Young
I am using a MacBook Pro running macOS Sierra Version 10.12.4 to upgrade my first six 32-bits Mac apps to 64-bits.
Each of the six apps worked fine when compiled for 32-bits.
Because my Mac Xojo license expired late last year, I used Xojo 2017 Release 1.1 to test the apps in the IDE for 64-bits and then compiled them for 64-bits using Xojo 2016 Release 3.
Launching each app twenty times, I recorded an exception upon close 20% to 50% of the time.
The Console log shows: “Service exited dur to signal: Segmentation fault: 11 sent by exc handler (0).
Can someone tell me in simple English what this means?
Thanks in advance.
Paul Young, CSoM
_______________________________________________

Xojo forum:

https://forum.xojo.co
Paul Young
2017-05-24 17:52:48 UTC
Permalink
Jon,

I suspect that whatever I am doing wrong I have been doing for a long time.

Could we go offline for one message?

Paul Young, CSoM
It's not really a difference between 64 bit and 32 bit. The real difference is that the 32 bit framework was somewhat more forgiving of things weren't always handled in the most correct way. If one follows proper coding and handling of objects, windows,controls, etc then there should be no problem. Relying on things to happen in a certain order is never a good idea.
Double check for circular references or references to controls not being destroyed properly. For example, an AddHandler directive that uses AddressOf instead of WeakAddressOf. If you don't use RemoveHandler, the app will continue to hold a reference to that object which doesn't get closed. If that handler fires and the window is closed, boom! You get this error. Same thing where you may need to use WeakRefs for objects that are properties in your Windows. Just because you close the window, it doesn't necessarily close the object.
There's all kinds of things and they can be hard to track down. But you'll end up with better code as a result.
Sent from my iPhone
Post by Paul Young
Jon,
Thank you for that information. Your explanation makes sense. I added code to close other windows in Window1.Close in case a User has the Help window (or other window) open and clicks the Window1 red close button.
This code was removed, the app compiled again for 64-bit and retested (clicking the red close button to close). I continue to see an exception at times so I must have other problems. Someone needs to write instructions on changes needed to be successful for compiling apps for 64-bit that worked correctly when compiled for 32-bit. Others must be having similar problems.
Paul Young, CSoM
Let me try to explain this further.
You tell your app to quit. The framework starts shutting everything down. But who knows what order it shuts the windows and closes everything. You cannot rely on a specific order of closing. Yet, that is what you are doing. Your Window1.close event is making sure Window2 let’s say is closed. But if Window2 is already gone that could be a problem. Even more of a problem is Window2 trying to report something back to Window1 after Window1 is already gone.
And if Window1 is strongly referenced in Window2 and vice versa, then you end up with a circular reference and the object never really gets destroyed - hence the crash. All sorts of stuff could be going on.
If you need to close other windows from your main window, then I would suggest doing it in the CancelClose event so you can control it a little bit more.
But I guarantee you that this is what is causing your problems.
Jon
Paul,
I see your problem.
The close event in a window should never be used to close other windows. You are trying to close or obtain information on a window that is already gone or something is still closing in that second window when the first window shuts down completely. That’s why you are getting your error.
Check for windows to be closed in the close event of the app never in the close event of other windows.
Jon
Thanks for your response, Tim, but Window1.Close just ensures that other windows are closed, followed by Quit.
Jon Ogden suggested other problems (below) that could create this issue but I have not found any of those.
Paul Young, CSoM
Check the Window’s .Close event.
Tim
I used the Xojo sale to buy another Mac license for Xojo for this year.
So, I am now debugging and compiling my test app in Xojo 2017 Release 1.1.
I have found nothing that I recognize would cause an exception when I click the Red Close button on Window1. I added a Menu Handler for File \ Quit in the App area with Quit as the code. I can step through the code without seeing an exception until I click on the Red Close button on Window1. At that point, the app closes and frequently an exception is thrown.
When compiled for 64-bits, using File \ Quit now quits the app 100% of the time (run of 20 launches) without throwing an exception but closing the app using the Red Close button of Window1 throws an exception about 50% of the time.
Does this suggest anything new to anyone?
Paul Young, CSoM
good idea....
I had a FileQuit in the MenuHandler without code. I deleted it, now it works in Debug and in compiled version.
I thought I need this MenuHandler also without code 🙈🙈🙈
Post by Jon Ogden
Sounds like you don't have code to quit in your
Menu handler.
Sent from my iPhone
Post by Claudius Sailer
all my 64Bit compiled Applications are running fine, but when I press Command-Q or select it in the Menu when I started them in debug mode no reaction. I have to kill it during Xojo.
Sorry I didn't know this "new" possibilities System.debuglog 🙈🙈🙈 thanks for this hint.
Post by Jon Ogden
MsgBox might not be the best thing as it interrupts the flow of events. What might be better are system.debuglog messages.
Also, I have no problem quitting my 64 bit apps from the debugger.
Sent from my iPhone
Post by Claudius Sailer
Hello,
I know it is painful, but when you can't find it, add MsgBox commands to your code. Than you can see until everything is fine and when it crashes.
MsgBox "Step 1"
MsgBox "Step 2"
and so on. So you can possibly find the problem easier.
I know that it is actually a problem that debug mode in 64Bit can't finished correctly.
Claudius
Post by Paul Young
Jon,
Would an instance of a method cause this? If so, how would one close/cancel/etc. the instance?
Paul
Post by Jon Ogden
Paul,
You can always look in the docs. But there is something in an object of code that is in your window or app that is not closing before the app tries to close. Make sure you have no circular references and make sure that all of your things like AddHandler references are undone. Some reference to something is being left open.
Jon
Sent from my iPhone
Post by Paul Young
a. making sure all integers are Int64
b. making sure all other Windows are closed before running the Window1.Close code
c. stopping the one timer that is running in Window1 (Timer1.Mode = 0)
d. stepping through the code (no problems until Window1 is closed and then, occasionally, an exception is thrown)
Is there an article available that summarizes changes to make to 32-bit code before compiling to 64-bit code?
Thanks in advance.
Paul Young, CSoM
Post by Jon Ogden
Thinking about this further, this is my educated guess.
The 32 bit framework shut things down in a certain order and you relied on that in your code to close out all your objects. The 64 bit framework is handling all that differently so the order you relied on before is now different. So some object is calling on or relying on some other object that is already closed. When that happens things crash.
You'll just have to step through things to figure it out. Don't rely on the framework doing things in a specific order.
Sent from my iPhone
Post by Jon Ogden
You have something in your code that is not truly 64 bit compatible. Maybe you are using a 32 bit integer some place where you should be using 64 bit.
There's not much that one can tell from that. But it looks to me like some object isn't closing correctly.
You don't have to do much to make 64 bit work. But you do have to adjust some things.
I would try stepping through the code when closing your app to find the thing causing the problem. It has likely always been there but Xojo and the 32 bit framework was a little more forgiving.
Sent from my iPhone
Post by Paul Young
I am using a MacBook Pro running macOS Sierra Version 10.12.4 to upgrade my first six 32-bits Mac apps to 64-bits.
Each of the six apps worked fine when compiled for 32-bits.
Because my Mac Xojo license expired late last year, I used Xojo 2017 Release 1.1 to test the apps in the IDE for 64-bits and then compiled them for 64-bits using Xojo 2016 Release 3.
Launching each app twenty times, I recorded an exception upon close 20% to 50% of the time.
The Console log shows: “Service exited dur to signal: Segmentation fault: 11 sent by exc handler (0).
Can someone tell me in simple English what this means?
Thanks in advance.
Paul Young, CSoM
_____________________________________________

Paul Young
2017-05-20 18:02:29 UTC
Permalink
Thank you Jon for responding.

The code steps through to closing the Main window and the exception is displayed after that. It is interesting that this does not happen 100% of the time.

I will continue to look at the code.

Thanks again,

Paul Young, CSoM
Post by Jon Ogden
You have something in your code that is not truly 64 bit compatible. Maybe you are using a 32 bit integer some place where you should be using 64 bit.
There's not much that one can tell from that. But it looks to me like some object isn't closing correctly.
You don't have to do much to make 64 bit work. But you do have to adjust some things.
I would try stepping through the code when closing your app to find the thing causing the problem. It has likely always been there but Xojo and the 32 bit framework was a little more forgiving.
Sent from my iPhone
Post by Paul Young
I am using a MacBook Pro running macOS Sierra Version 10.12.4 to upgrade my first six 32-bits Mac apps to 64-bits.
Each of the six apps worked fine when compiled for 32-bits.
Because my Mac Xojo license expired late last year, I used Xojo 2017 Release 1.1 to test the apps in the IDE for 64-bits and then compiled them for 64-bits using Xojo 2016 Release 3.
Launching each app twenty times, I recorded an exception upon close 20% to 50% of the time.
The Console log shows: “Service exited dur to signal: Segmentation fault: 11 sent by exc handler (0).
Can someone tell me in simple English what this means?
Thanks in advance.
Paul Young, CSoM
_______________________________________________

Xojo forum:

https://foru
Continue reading on narkive:
Loading...