|
Unfortunately stack overflow just crash / exit the program when they happen in UWP App. It can't be caught and broke into with the debugger. At least it looks like it (using Visual Studio 2017 professional).
I enabled mixed mode debugging, enabled all exception, native exceptions, managed assistance, downloaded MS symbols, etc...
Whatever I do the program gently churn along and then ... close suddenly.
All I have left is this post mortem line in the debug output:
The thread 0x1ce4 has exited with code -2147023895 (0x800703e9).
I have been scratching my head all day for that. Unfortunately, I have a few weeks of changes that were not tested and I am a bit lost as to what could cause that... Plus it might have been there before anyway...
Any idea on how to track what could be the cause of that?
As a side note my app is compiled for x64. I also tried to compile for x86. Same results.
Unfortunately there is no MSIL targets possible for UWP, apparently... (Which, I imagine, would offer better debugging regarding StackOverflow)
[EDIT]
The plot thickens though.
I just tried a simple test UWP App where I changed the constructor as follow:
public App()
{
this.InitializeComponent();
this.Suspending += OnSuspending;
var u = Moo(42);
}
public static int Moo(int seed)
{
var r = new Random(seed);
var next = r.Next();
if (next == 0)
return seed;
return Moo(next);
}
And the debugger successfully broke on my code... Somehow I have some suspicion on the UI code... but I didn't set the model at all in one test, i.e. no model or data context => no binding and update, stumped....
modified 28-Apr-18 12:07pm.
|
|
|
|
|
Stackoverflow usually means you have some recursive code that is consuming all the space.
|
|
|
|
|
yeah... but which code? that is exactly my question?
I feel asleep reading the last month of commit...
And VS doesn't stop when the stack overflow happen, so I dunno where it is..
It's where I need a tip. How to break on the damn recursive code?
|
|
|
|
|
Super Lloyd wrote: but which code? that is exactly my question?
Of course it is, but only someone who knows the code can figure it out.
|
|
|
|
|
Do you think you can add something that will actually help?! 
modified 27-Apr-18 9:57am.
|
|
|
|
|
well you don't know where the stack overflow occurs. 
|
|
|
|
|
|
If you have access to an AOP system, it is probably worth decorating your method calls with pre and post logging to see which methods are being called and not returned from.
This space for rent
|
|
|
|
|
Mm.. thanks, that's an idea worth investigating! 
|
|
|
|
|
Just a thought, but check through your property setters. You are looking for instances where the setter uses the property name in place of the member. Something like this
private int myInt;
public int MyInt
{
set { MyInt=value; }
}
This space for rent
|
|
|
|
|
I thought about it...
It's just, it's a lot of code to review for a shot in the dark... damn VS let me down there! 
|
|
|
|
|
H, Lloyd,Quote: but which code? that is exactly my question?
Knowing you to be an advanced programmer capable of impressive work, like your serializer, I think you must have some ideas about where in the code the recursion, or whatever, occurs.
Could you a counter-incrementing snippet in those places, and, when some reasonable limit was reached, hit a break=point ?
Sorry for the vagueness of all this, but, without a detailed over-view of the code ... it's all I got
cheers, Bill
«... thank the gods that they have made you superior to those events which they have not placed within your own control, rendered you accountable for that only which is within you own control For what, then, have they made you responsible? For that which is alone in your own power—a right use of things as they appear.» Discourses of Epictetus Book I:12
|
|
|
|
|
Thanks Bill!
Yea that was my thought and wrote such a utility / debugging helper method!
But then I thought, damn, being a shot in the dark I have to put in so many places... 
I was thinking about it today (from the comfort of my home..) and.. I hardly can think of any place with recursion in the code... 
|
|
|
|
|
Give your threads a name when creating one. It makes debugging a whole lot easier 
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
It's so 2000 and late!
Now with Task madness, that doesn't work so well!
|
|
|
|
|
Sure it works. Windows hasn't been changed that much.
static class Program
{
[STAThread]
static void Main()
{
Thread.CurrentThread.Name = String.Format("Main UI thread for", Application.ProductName);
Task BackgroundJsonLoader = Task.Factory.StartNew(() =>
{
Thread.CurrentThread.Name = "BackgroundJsonLoader_C71B0546796D46A894925EAF6A0CF420";
Debug.WriteLine(Thread.CurrentThread.Name);
Debugger.Break();
});
When the debugger breaks, go the menu and select from "Debug" the submenu "Windows", the item "Threads" (Ctrl-D, T). You'll now have a list of all active threads. The named ones were created by you, in code. That gives us not just the advantage that we now can identify any thread or task by name, we can also see whether we spawned it or some third-party library.
Very easy to do, rarely ever done. The reason I added a GUID in there is to locate it quickly, as it is always my first line of code on the start of each thread or task.
--Downloading 2017 Community Edition now, will try it on a UWP app once the download is done
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
modified 28-Apr-18 7:28am.
|
|
|
|
|
That's worth writing up as a Tip.
|
|
|
|
|
Thanks! I'll post a cleaned up version later today then
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
what about
await Task.Delay(100)
Boom thread name lost!
modified 28-Apr-18 11:34am.
|
|
|
|
|
Add an exception-handler to your task; they don't dissappear into thin air without notice, unless you allow them to.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
I do. TO all.
StackOverflow is uncatchable, at least in UWP. Sorry if that wasn't clear in my message, I thought the fact that Visual Studio debugger just CANT stop and break on them would have been enough of an indication....
|
|
|
|
|
Upvoted: that kind of advice is "worth its weight in gold" !
«... thank the gods that they have made you superior to those events which they have not placed within your own control, rendered you accountable for that only which is within you own control For what, then, have they made you responsible? For that which is alone in your own power—a right use of things as they appear.» Discourses of Epictetus Book I:12
|
|
|
|
|
Can anyone volunteer a 3D printer that does marble or granite stones to print the post for Bill?
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
sadly it is useless advice...
Just checked this barely modified samples... does not work,...
Task.Factory.StartNew(async () =>
{
Thread.CurrentThread.Name = "BackgroundJsonLoader_C71B0546796D46A894925EAF6A0CF420";
Debug.WriteLine(Thread.CurrentThread.Name);
await Task.Delay(10);
Debug.WriteLine(Thread.CurrentThread.Name);
}).Wait();
In fact.. this snippet will be more instructive:
Task.Run(async () =>
{
Console.WriteLine("ThreadID: " +Thread.CurrentThread.ManagedThreadId);
Console.WriteLine("TaskId: " + Task.CurrentId);
await Task.Delay(10);
Console.WriteLine("ThreadID: " + Thread.CurrentThread.ManagedThreadId);
Console.WriteLine("TaskId: " + Task.CurrentId);
}).Wait();
modified 28-Apr-18 11:54am.
|
|
|
|
|
Sadly this is a poor,misleading and contrived usage of Task.
In task heavy code that won't work, for the simple reason that as soon as and every time one write await the next line is, potentially, on another thread...
i.e. check that out
Task.Factory.StartNew(async () =>
{
Thread.CurrentThread.Name = "BackgroundJsonLoader_C71B0546796D46A894925EAF6A0CF420";
Debug.WriteLine(Thread.CurrentThread.Name);
await Task.Delay(10);
Debug.WriteLine(Thread.CurrentThread.Name);
});
In fact.. just try that and understand the magnitude of the problem (not my stackoverflow problem, mind you, the problem of tracking task as they go)
Task.Run(async () =>
{
Console.WriteLine("ThreadID: " +Thread.CurrentThread.ManagedThreadId);
Console.WriteLine("TaskId: " + Task.CurrentId);
await Task.Delay(10);
Console.WriteLine("ThreadID: " + Thread.CurrentThread.ManagedThreadId);
Console.WriteLine("TaskId: " + Task.CurrentId);
}).Wait();
}
modified 28-Apr-18 11:53am.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
