← Back to index

Immediate crash on opening (v0.7.2 Win7 x64)

Andrew Reece
#16986
Hi,

I just bought this on itch.io. v0.7.2 (the latest at the time of posting) crashes immediately on opening with the 
1
codeclap has stopped working
message.

v0.6.4 opens without a problem.

Let me know if I can provide any other info.

Cheers,
Andrew
Edited by Andrew Reece on Reason: Initial post
spx
#16987
That's not a known issues so I'd love to get a few hints on where to look for this.

A small list of things that come to my mind right away:
  • I guess you probably have tried executing from a clean directory without overwriting any files?
  • Are you using some command line parameters or are you simply double clicking the .exe in the explorer?
  • If you have visual studio installed windows should give you the option to debug the stopped program. There you should be able to see the function and offset into the function where the fault occurred, that could be one of the most helpful hints.


Thanks
Andrew Reece
#16988
I unzipped the file and double-clicked the exe inside.


There's no PDB in the folder, so VS hasn't loaded symbols.

I'll include the details I can give you below, but I'm not sure how helpful they are... If you want to give me the PDB, I'm happy to be more specific.

Disassembly 
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
   000000013FE74B60  mov         qword ptr [rsp+8],rcx  
   000000013FE74B65  sub         rsp,38h  
   000000013FE74B69  mov         rdx,qword ptr [rsp+40h]  
   000000013FE74B6E  mov         cx,1  
   000000013FE74B72  call        000000013FE74A50  
   000000013FE74B77  mov         qword ptr [rsp+20h],rax  
   000000013FE74B7C  cmp         qword ptr [rsp+20h],0  
   000000013FE74B82  je          000000013FE74BB7  
   000000013FE74B84  mov         rax,qword ptr [rsp+20h]  
   000000013FE74B89  mov         rax,qword ptr [rax]  
   000000013FE74B8C  mov         qword ptr [rsp+28h],rax  
   000000013FE74B91  call        000000013FE73D50  
   000000013FE74B96  mov         rax,qword ptr [rax+30h]  
   000000013FE74B9A  mov         rcx,qword ptr [rsp+28h]  
>  000000013FE74B9F  cmp         qword ptr [rcx+78h],rax  
   000000013FE74BA3  jne         000000013FE74BB1  
   000000013FE74BA5  mov         rax,qword ptr [rsp+20h]  
   000000013FE74BAA  mov         rax,qword ptr [rax]  
   000000013FE74BAD  jmp         000000013FE74BB9  
   000000013FE74BAF  jmp         000000013FE74BB5  
   000000013FE74BB1  xor         eax,eax  
   000000013FE74BB3  jmp         000000013FE74BB9  
   000000013FE74BB5  jmp         000000013FE74BB9  
   000000013FE74BB7  xor         eax,eax  
   000000013FE74BB9  add         rsp,38h 
   000000013FE74BBD  ret


Call stack 
1
2
3
4
5
6
7
8
>	codeclap.exe!000000013fe74b9f()	Unknown
 	codeclap.exe!000000013fe75176()	Unknown
 	codeclap.exe!000000013fe764d6()	Unknown
 	codeclap.exe!000000013fe49208()	Unknown
 	codeclap.exe!000000013fed4548()	Unknown
 	codeclap.exe!000000013fee0358()	Unknown
 	kernel32.dll!00000000775d59cd()	Unknown
 	ntdll.dll!000000007783385d()	Unknown


Exception error 
1
Unhandled exception at 0x000000013FE74B9F in codeclap.exe: 0xC0000005: Access violation reading location 0x0000000000000078.
spx
#16989
ah seems I wrongly assumed that most function addresses are also still present in the Windows build (even without the full debug information).
I've uploaded the pdbs to itch.io and they should match the release build (I hope, after switching to msvc I never actually made sure that this is true). Just extract/copy them into the same directory and you should get a more explanatory trace.
Edited by spx on
Andrew Reece
#16992
Thanks. The crash is in this file: 

1
z:\impromptu\ws2\codeclap\iui.c


and looks like it's on line 1879.

Call stack: 
1
2
3
4
5
6
7
>	codeclap.exe!iuiCurrentPanel(iui_command * IgnoreCommand) Line 1879	C
 	codeclap.exe!iuiGenericWidgetBegin(iui_type Type, iui_rect Margin, iui_rect Padding) Line 2042	C
 	codeclap.exe!iuiGenericWidget(iui_type DrawType, iui_state DrawState, iui_rect Margin, iui_rect Padding, float ForceWidth, const char * Label, iui_align Align) Line 2361	C
 	codeclap.exe!iuiRadioButton(const char * Label, iui_type Type, int * Option) Line 3798	C
 	codeclap.exe!DebuggerFrontendProcess(debugger_input * Input) Line 13942	C
 	codeclap.exe!CodeclapFrontendThread(void * lpParam) Line 975	C
 	[External Code]
spx
#16994
Thanks, the debug information matches with the information you have provided before.
I may have a clue whats going on here and will have to do some checking on different machines tomorrow.

One additional thing that may be helpful, what CPU are you using?
Mārtiņš Možeiko
#17000
spx
ah seems I wrongly assumed that most function addresses are also still present in the Windows build (even without the full debug information).

For that you typically build with "/PDBSTRIPED:second_file.pdb" argument. This will contain only public symbols + FPO records for stack walking, which you can distribute with your binaries (it is also smaller). You can use this argument in additional to normal "/PDB:file.pdb" argument - it basically creates two pdb files, one for you, one for distribution.
Andrew Reece
#17001
spx
Thanks, the debug information matches with the information you have provided before.
I may have a clue whats going on here and will have to do some checking on different machines tomorrow.

One additional thing that may be helpful, what CPU are you using?


No worries, glad to hear it.

It's an Intel i5-3570K, which I think is Ivy Bridge.
spx
#17007
azmr
No worries, glad to hear it.
It's an Intel i5-3570K, which I think is Ivy Bridge.


Thank you for the quick report. During transit to msvc I replaced usage of bsr with lzcnt without putting too much thought into it. On pre-haswell processors this executes (despite not being supported) but produces wrong results leading to this behavior.
Edited by spx on
spx
#17083
Unfortunately I will have to wait a few weeks to test on an ivy bridge CPU myself but 0.7.5 should work for you again.
Edited by spx on
← Back to index