[VB.NET] Debugger stopt steeds op dezelfde regel

[Atmoz]

Beste,

In een tooltje wat ik heb gemaakt (VB.NET 2010) heb ik iets heel vreemds aan de hand:
Zodra ik het programma laat "lopen" (zonder vaste breakpoints te hebben gezet), en ik druk op "Break-all" (het pauze icoontje oftwewel "Ctrl-Alt+Break") dan stopt de debugger ALTIJD op dezelfde lijn. Dus altijd op dezelfde regel code...

Hoe is zoiets mogelijk? En moet ik me hier zorgen om maken? Ik heb het idee dat er iets niet goed zit. Hij zou toch normaliter gewoon redelijk "random" moeten pauzeren? Er wordt een flinke lap code doorlopen, en toch stopt hij steeds op diezelfde regel. Ook als ik die betreffende regel naar beneden zet door er een klein (test) stukje code voor te schrijven.

Wie weet wat hier aan de hand is? En misschien nog belangrijker: kan dit kwaad? c.q. moet ik me zorgen maken om dat stukje code? Zou daar iets niet goed in staan?

Thanks!

[RobIII]

Als het programma doet wat 't moet doen; wat is je probleem dan?
Heb je een daadwerkelijk probleem? Of is het iets dat je zomaar opgevallen is?

Er is zeer waarschijnlijk niets aan de hand. Of je doet op die regel een call die gewoonweg de meeste tijd van het hele proces inneemt, of dat is de eerste plek waar de CPU er aan toekomt je "break-all" te verwerken. En er zijn waarschijnlijk nog wel 25 redenen te bedenken. Maar tenzij je een probleem hebt dat je probeert op te lossen snap ik niet waarom je deze vraag/vragen überhaupt zo stellen (noch wat voor zinnigs we hier op zouden moeten zeggen zonder daadwerkelijke code te zien / kennis van het proces te hebben; het is voor ons zo ook koffiedik kijken).

[Atmoz]

RobIII schreef op dinsdag 02 juni 2015 @ 11:06:
Als het programma doet wat 't moet doen; wat is je probleem dan?
Heb je een daadwerkelijk probleem? Of is het iets dat je zomaar opgevallen is?

Er is zeer waarschijnlijk niets aan de hand. Of je doet op die regel een call die gewoonweg de meeste tijd van het hele proces inneemt, of dat is de eerste plek waar de CPU er aan toekomt je "break-all" te verwerken. En er zijn waarschijnlijk nog wel 25 redenen te bedenken. Maar tenzij je een probleem hebt dat je probeert op te lossen snap ik niet waarom je deze vraag/vragen überhaupt zo stellen (noch wat voor zinnigs we hier op zouden moeten zeggen zonder daadwerkelijke code te zien / kennis van het proces te hebben; het is voor ons zo ook koffiedik kijken).

Thanks voor je snelle reactie RobIII

Nou, het zit eigenlijk zo:
Ik vroeg me dat in eerste instantie af (nieuwsgierigheid + wilde het gewoon weten ter lering ende vermaeck).
Er was natuurlijk een (grote) kans dat iemand hier wist waardoor zoiets komt. (het is toch best apart, want in andere stukken is het gewoon -zoals je zou verwachten- wél random).

Bovendien hebben we hier (ik werk er met nog een collega aan) misschien een probleem in dit stukje code, het is nog te vroeg om stukjes code te posten. Ik had gewoon gehoopt dat er een eenduidig antwoord op mogelijk zou zijn. Google verteld me er in ieder geval niet veel over

Persoonlijk had ik nog iets in gedachten zoals dat bij video is: bepaalde "key-frames" op enkele plaatsen, waardoor het "jumpen" naar bepaalde stukken makkelijker/sneller wordt. (in een ontzettend snelle run met veel code boeit het namelijk toch niet waar je stopt, dat kun je als mens toch niet zo snel bepalen). Dus om het dan wat "lichter" voor de CPU te maken stopt hij gewoon op bepaalde (vaste) plaatsen. Dat was dan een idee wat bij me op kwam he

[Verwijderd]

Paste die betreffende line eens dan.

[RobIII]

Verwijderd schreef op dinsdag 02 juni 2015 @ 12:43:
Paste die betreffende line eens dan.

Zonder context heb je daar verdomd weinig aan.

[Verwijderd]

RobIII schreef op dinsdag 02 juni 2015 @ 14:07:
[...]

Zonder context heb je daar verdomd weinig aan.

Oh nee? Wat dacht je van een synchrone pop van message queue vs. (per ongeluk) een endless loop in een worker thread? Thread en betreffende regel zeggen over het algemeen meer dan in een glazen bol kijken.

[RobIII]

Verwijderd schreef op dinsdag 02 juni 2015 @ 17:25:
[...]

Oh nee? Wat dacht je van een synchrone pop van message queue vs. (per ongeluk) een endless loop

Dat zal allemaal best, maar die code kan er natuurlijk zo uit zien:

C#:

var myresult = SomeObject.ProcessFoo(foo, bar, baz);

Daar zie je, zéker zonder context, geen fuck aan.

[Verwijderd]

RobIII schreef op dinsdag 02 juni 2015 @ 17:29:
[...]

Dat zal allemaal best, maar die code kan er natuurlijk zo uit zien:

C#:

var myresult = SomeObject.ProcessFoo(foo, bar, baz);

Daar zie je, zéker zonder context, geen fuck aan.

Precies.
En omdat jij en ik niet weten hoe die code eruit ziet, vraag ik ernaar.

[NMe]

Je vroeg naar één regel. Er zijn bij dit soort problemen meer regels relevant dan eentje. En om die code was al gevraagd voordat jij je oneliner postte waarin je dus om het verkeerde ding vroeg.

Kunnen we nu weer ontopic?