Hard Light Productions Forums

Modding, Mission Design, and Coding => The FRED Workshop => Topic started by: Bryan See on August 21, 2015, 10:01:27 am

Title: FRED Crashes
Post by: Bryan See on August 21, 2015, 10:01:27 am: I've been FREDding for years, and I've got the latest nightly FS2_Open 3.7.3 AVX build.

The reason I am posting here is that FRED keeps on crashing when its main window isn't focused after some while, or after being inactive for some time. For example, when I looked away from FRED to refer something, then FRED crashes. This problem gets annoying for me and others for that matter, so I believe this needs to be resolved as soon as possible.

On an ending note, wxFRED is expected to solve all these problems by integrating the UI cross-platform, the recently released Windows 10 included. wxFRED is supposed to replace FRED, but... the development is stalled. However, I do have an interest in continuing development of wxFRED for the sake of the SCP's future.
Title: Re: FRED Crashes
Post by: karajorma on August 21, 2015, 05:39:15 pm: Have you tried running the debug version of FRED? Does the same thing happen?
Title: Re: FRED Crashes
Post by: Bryan See on August 21, 2015, 09:57:30 pm: Yes, I tried running the debug version of FRED? The same thing happen.
Title: Re: FRED Crashes
Post by: AdmiralRalwood on August 21, 2015, 10:46:43 pm: So what does the fred2_open.log say?
Title: Re: FRED Crashes
Post by: Bryan See on September 06, 2015, 06:39:05 am: The fred 2 open logs say nothing but problems with modpack.
Title: Re: FRED Crashes
Post by: karajorma on September 07, 2015, 01:06:06 am: Well fix those first then. It's quite easy to crash FRED if you have bad data.
Title: Re: FRED Crashes
Post by: Bryan See on September 30, 2015, 11:18:30 am: I'm using AVX because my PC's CPU is AVX capable. And I have Windows 10. Keep it up, Karajoma.
Title: Re: FRED Crashes
Post by: karajorma on September 30, 2015, 09:01:54 pm: So does FRED report any errors with the mod now? We can help you fix those if you can't figure them out.
Title: Re: FRED Crashes
Post by: Bryan See on October 08, 2015, 10:23:02 pm: Yes.

But FRED seems to be crashing on Windows 10. For missions with large numbers of objects and wings, using a retail to create another wing will result in its crash.
Title: Re: FRED Crashes
Post by: karajorma on October 09, 2015, 12:08:25 am: The limits on retail are much lower than on SCP versions. IIRC over 100 ships in a mission will crash it.
Title: Re: FRED Crashes
Post by: Bryan See on October 09, 2015, 12:35:06 pm: Model instancing will solve this problem, but I believe there are other modern methods of solving this for the sake of performance, reliability and stability.

However, I do have one more concern.

When I open up the ship list, FRED crashes without displaying an "Assertion Failed" message. The log once again comes up empty, as what happened to its FSO counterpart.

Here's the fred2_open.log file, which is pretty much larger:

Code: [Select]
... Allocating space for at least 6 new ship subsystems ... a total of 200 is now available (6 in-use). Parse complete. 0 errors. 0 warnings. Adding default sun. Requested file kato_ao.dds found at: C:\Program Files (x86)\GOG.com\Freespace 2\ShatteredStars-dev1\data\maps\Kato_AO.dds Requested file kato_ao-glow.dds found at: C:\Program Files (x86)\GOG.com\Freespace 2\ShatteredStars-dev1\data\maps\Kato_AO-glow.dds Resetting dynamic tree node limit from 0 to 0... Resetting dynamic tree node limit from 0 to 0... Found required string [#Mission Info] Found required string [$Version:] Found required string [$Name:] Found required string [$Author:] Found required string [$Created:] Found required string [$Modified:] Found required string [$Notes:] Found required string [$End Notes:] Found required string [$Mission Desc:] Found required string [$end_multi_text] Found optional string [+Game Type Flags:] Found optional string [+Flags:] Found optional string [+Disallow Support:] Found optional string [+Hull Repair Ceiling:] Found optional string [+Subsystem Repair Ceiling:] Found optional string [+Viewer pos:] Found optional string [+Viewer orient:] Found optional string [$AI Profile:] Found required string [#Command Briefing] Found required string [#Briefing] Found required string [$start_briefing] Found required string [$num_stages:] Found required string [$end_briefing] Found required string [#Debriefing_info] Found required string [$Num stages:] Optional string [#Alternate Types:] not found Optional string [#Callsigns:] not found Found required string [#Players] Found required string [$Starting Shipname:] Found required string [$Ship Choices:] Found optional string [+Weaponry Pool:] Found required string [#Objects] Found required string [$Name:] Found required string [$Name:] Found required string [$Class:] Found required string [$Team:] Found required string [$Location:] Found required string [$Orientation:] Found required string [$AI Behavior:] Found required string [$Cargo 1:] Found optional string [+Initial Velocity:] Found optional string [+Initial Hull:] Found required string [+Subsystem:] Found required string [$Arrival Location:] Found required string [$Arrival Cue:] Found required string [$Departure Location:] Found required string [$Departure Cue:] Found required string [$Determination:] Found optional string [+Flags:] Found optional string [+Flags2:] Optional string [+Group:] not found Found optional string [+Use Table Score:] Found optional string [+Score:] Found required string [#Wings] Found required string [#Events] Found required string [#Goals] Found required string [#Waypoints] Found required string [#Messages] Found required string [#Reinforcements] Found required string [#Background bitmaps] Found required string [$Num stars:] Found required string [$Ambient light level:] Found optional string [+Nebula:] Found required string [+Color:] Found required string [+Pitch:] Found required string [+Bank:] Found required string [+Heading:] Found required string [#Asteroid Fields] Found required string [#Music] Found required string [$Event Music:] Found required string [$Briefing Music:] Found required string [#End]
FYI, I've opened an issue on GitHub. I'm running a decent nightly build of FSO/FRED2Open using AVX.
Title: Re: FRED Crashes
Post by: niffiwan on October 09, 2015, 05:35:56 pm: Yo, please provide the whole log. If it's massive, please pastebin it (or use a similar service) then post the link.
Title: Re: FRED Crashes
Post by: Bryan See on October 10, 2015, 02:51:30 am: Here's the log on Dropbox: https://www.dropbox.com/s/m8a6unvyim73voh/fred2_open.log?dl=0 (https://www.dropbox.com/s/m8a6unvyim73voh/fred2_open.log?dl=0)
Title: Re: FRED Crashes
Post by: niffiwan on October 10, 2015, 04:35:59 am: Firstly, I think it's likely that this is an issue with assets. I'm sure there's many other FREDers opening the ship list all the time without crashes.

And, I can see a bunch of warnings that you should fix:

In the GHC Custos, probably defined in C:\Program Files (x86)\GOG.com\Freespace 2\ShatteredStars-dev1\data\tables\ss-shp.tbm

Code: [Select]
Stuffed string = [turret05] WARNING: "Unable to find WEAPON_LIST_TYPE string "Warhammer#Sanctus" in stuff_int_list Many possible sources for this error. Get a programmer!" at parselo.cpp:2819 Stuffed string = [turret06] WARNING: "Unable to find WEAPON_LIST_TYPE string "Warhammer#Sanctus" in stuff_int_list Many possible sources for this error. Get a programmer!" at parselo.cpp:2819
GHFg Decuria; in the same file

Code: [Select]
Stuffed string = [turret30] WARNING: "Unable to find WEAPON_LIST_TYPE string "HV Beam" in stuff_int_list Many possible sources for this error. Get a programmer!" at parselo.cpp:2819 Stuffed string = [turret31] WARNING: "Unable to find WEAPON_LIST_TYPE string "HV Beam" in stuff_int_list Many possible sources for this error. Get a programmer!" at parselo.cpp:2819 Stuffed string = [turret32] WARNING: "Unable to find WEAPON_LIST_TYPE string "LT Beam" in stuff_int_list Many possible sources for this error. Get a programmer!" at parselo.cpp:2819 Stuffed string = [turret33] WARNING: "Unable to find WEAPON_LIST_TYPE string "LT Beam" in stuff_int_list Many possible sources for this error. Get a programmer!" at parselo.cpp:2819 Stuffed string = [turret34] WARNING: "Unable to find WEAPON_LIST_TYPE string "LT Beam" in stuff_int_list Many possible sources for this error. Get a programmer!" at parselo.cpp:2819 Stuffed string = [turret35] WARNING: "Unable to find WEAPON_LIST_TYPE string "LT Beam" in stuff_int_list Many possible sources for this error. Get a programmer!" at parselo.cpp:2819

AuFg Marchion, in the same file.

Code: [Select]
Stuffed string = [1stFleet_BlueStripes] WARNING: "Team name 1stFleet_BlueStripes is invalid. Teams must be defined in colors.tbl." at ship.cpp:2447
AuD Bulwark

Code: [Select]
Stuffed string = [1stFleet] WARNING: "Team name 1stFleet is invalid. Teams must be defined in colors.tbl." at ship.cpp:2447
Code: [Select]
WARNING: "Pbank capacity not specified for ballistic-primary-enabled ship GRF Kavi. Defaulting to capacity of 1 per bank." at ship.cpp:4994 WARNING: "Pbank capacity specified for non-ballistic-primary-enabled ship AuB Retaliator. Resetting capacities to 0. To fix this, add a ballistic primary to the list of allowed primaries." at ship.cpp:4986
In short, get rid of all those warning 1st, then we'll look at what could be causing the crash.

Also, you might want to temporarily rename your debug_filter.cfg file so that the log has less data in it; at least until all the warning are gone.
Title: Re: FRED Crashes
Post by: m!m on October 10, 2015, 10:24:56 am: I agree that the warnings should be fixed but bad data shouldn't be able to crash FSO.
@Bryan See: How big is your modpack? If I can reproduce the crash using your data I should be able to replace it with a proper error message. I think you mentioned in another thread that FSO also suffers from this issue so it's probable that the source lies within the shared code of FRED and FSO.
Title: Re: FRED Crashes
Post by: Bryan See on October 11, 2015, 09:45:22 am: My modpack is about 2.48 GB, because I intend it to become the largest modpack ever assembled after Inferno. I fixed all errors, and now uploading it to GitHub.

Yet, FRED has crashed again after being inactive for a while. The log (https://www.dropbox.com/s/bi71c2bq3z74gmb/fred2_open_111015.log?dl=0) I provided below once again does not show any sign of "assertion failed" message. I am using the AVX branch, not the Standard, SSE or SSE2.
Title: Re: FRED Crashes
Post by: m!m on October 11, 2015, 09:58:14 am: That's definitely too big for me to download (GitHub is also not a good host for such large amounts of data).
You either have to reduce the size of the modpack or run FSO using a debugger which will show us where and why the crash occurs.
Title: Re: FRED Crashes
Post by: niffiwan on October 11, 2015, 05:29:55 pm: Yeah, the lack of Assertion is what m!m wants to fix for you.

To run FSO in a debugger, see this post (http://www.hard-light.net/forums/index.php?topic=82688.msg1479356#msg1479356).
Title: Re: FRED Crashes
Post by: m!m on October 12, 2015, 05:02:40 am: That post is a bit out of date so don't use it yet. I'll see what I can do about updating that.

EDIT: Updated guide is available here: http://www.hard-light.net/wiki/index.php/What_to_do_when_SCP_coders_cannot_reproduce_your_fs2_open_crashes%3F
Title: Re: FRED Crashes
Post by: Bryan See on October 12, 2015, 11:50:18 am: The modpack is here on GitHub. Head over to the Shattered Stars (http://www.hard-light.net/forums/index.php?topic=88909.new#new) thread to get it, if you want to fix it for me. I am having problems with my FS2/FRED open builds, using AVX.

RE to m!m and niffiwan regarding the updated guide, thank you for this suggestion. I'll try this.
Title: Re: FRED Crashes
Post by: Bryan See on October 20, 2015, 10:39:54 am: Hello again,

I've been using FRED (both release and debug builds) without administrative privileges on Windows 10, which is known to have cause stability issues.

I'm running the debug build of FRED via VS2015 Community Edition. At one point, I've got the assert message on wings.cpp:

Code: [Select]
Assert: Wings[wing].special_ship >= 0 && Wings[wing].special_ship < Wings[wing].wave_count File: wing.cpp Line: 65 ntdll.dll! NtWaitForSingleObject + 12 bytes KERNELBASE.dll! WaitForSingleObject + 18 bytes fred2_open_3_7_3_AVX-DEBUG.exe! SCP_DumpStack + 354 bytes fred2_open_3_7_3_AVX-DEBUG.exe! WinAssert + 194 bytes fred2_open_3_7_3_AVX-DEBUG.exe! mark_wing + 103 bytes fred2_open_3_7_3_AVX-DEBUG.exe! wing_editor::OnPrev + 202 bytes fred2_open_3_7_3_AVX-DEBUG.exe! _AfxDispatchCmdMsg + 195 bytes fred2_open_3_7_3_AVX-DEBUG.exe! CCmdTarget::OnCmdMsg + 858 bytes fred2_open_3_7_3_AVX-DEBUG.exe! CDialog::OnCmdMsg + 66 bytes fred2_open_3_7_3_AVX-DEBUG.exe! CWnd::OnCommand + 416 bytes fred2_open_3_7_3_AVX-DEBUG.exe! wing_editor::OnCommand + 127 bytes fred2_open_3_7_3_AVX-DEBUG.exe! CWnd::OnWndMsg + 134 bytes fred2_open_3_7_3_AVX-DEBUG.exe! CWnd::WindowProc + 68 bytes fred2_open_3_7_3_AVX-DEBUG.exe! AfxCallWndProc + 267 bytes fred2_open_3_7_3_AVX-DEBUG.exe! AfxWndProc + 181 bytes USER32.dll! CharNextW + 115 bytes USER32.dll! CallWindowProcW + 768 bytes USER32.dll! DispatchMessageW + 1328 bytes USER32.dll! PeekMessageW + 1353 bytes ntdll.dll! KiUserCallbackDispatcher + 54 bytes USER32.dll! SendMessageW + 323 bytes USER32.dll! LoadCursorFromFileW + 16683 bytes USER32.dll! LoadCursorFromFileW + 15288 bytes USER32.dll! LoadCursorFromFileW + 8738 bytes USER32.dll! LoadCursorFromFileW + 5842 bytes USER32.dll! CharNextW + 115 bytes USER32.dll! CallWindowProcW + 768 bytes USER32.dll! DispatchMessageW + 593 bytes USER32.dll! IsDialogMessageW + 257 bytes USER32.dll! IsDialogMessage + 78 bytes fred2_open_3_7_3_AVX-DEBUG.exe! CWnd::IsDialogMessageA + 148 bytes fred2_open_3_7_3_AVX-DEBUG.exe! CWnd::PreTranslateInput + 125 bytes fred2_open_3_7_3_AVX-DEBUG.exe! CDialog::PreTranslateMessage + 297 bytes fred2_open_3_7_3_AVX-DEBUG.exe! CWnd::WalkPreTranslateTree + 174 bytes fred2_open_3_7_3_AVX-DEBUG.exe! AfxInternalPreTranslateMessage + 99 bytes fred2_open_3_7_3_AVX-DEBUG.exe! CWinThread::PreTranslateMessage + 42 bytes fred2_open_3_7_3_AVX-DEBUG.exe! AfxPreTranslateMessage + 45 bytes fred2_open_3_7_3_AVX-DEBUG.exe! AfxInternalPumpMessage + 253 bytes fred2_open_3_7_3_AVX-DEBUG.exe! CWinThread::PumpMessage + 19 bytes fred2_open_3_7_3_AVX-DEBUG.exe! CWinThread::Run + 180 bytes fred2_open_3_7_3_AVX-DEBUG.exe! CWinApp::Run + 108 bytes fred2_open_3_7_3_AVX-DEBUG.exe! AfxWinMain + 308 bytes fred2_open_3_7_3_AVX-DEBUG.exe! WinMain + 24 bytes fred2_open_3_7_3_AVX-DEBUG.exe! invoke_main + 30 bytes fred2_open_3_7_3_AVX-DEBUG.exe! __scrt_common_main_seh + 346 bytes fred2_open_3_7_3_AVX-DEBUG.exe! __scrt_common_main + 13 bytes fred2_open_3_7_3_AVX-DEBUG.exe! WinMainCRTStartup + 8 bytes KERNEL32.DLL! BaseThreadInitThunk + 36 bytes ntdll.dll! RtlSetCurrentTransaction + 212 bytes ntdll.dll! RtlSetCurrentTransaction + 159 bytes
At one point at the wings section of the mission file, one of the wings' arrival location is changed to "Cable TV", and the Special Ship is set to a negative value of 1.

Code: [Select]
$Special Ship: -1 ;! Brahma 1 $Arrival Location: Cable TV ... $Departure Anchor: <error>
Going to upload one of my large missions on GitHub very soon to test it out.

EDIT: To clarify the problem of special ship negative value and the arrival location as Cable TV.

EDIT #2: To clarify the problem of departure anchor set to <error>.
Title: Re: FRED Crashes
Post by: mjn.mixael on October 20, 2015, 12:34:26 pm: For whatever it's worth.. I've been FREDing on Win10 for a few weeks with no stability issues.
Title: Re: FRED Crashes
Post by: AdmiralRalwood on October 20, 2015, 04:26:45 pm: Something has gone horribly wrong if "Arrival Location" is getting set to "Cable TV"; if I had to guess, the arrival_location is probably also -1, because an out-of-bounds array access is the only way I can think of for that string to get written there (and "Cable TV" is the last string of the previously-defined array). In fact, the "$Departure Anchor: <error>" is also only written if the departure_anchor is negative, so it sounds like an object with nothing but the default initialization values is getting saved for some reason.
Title: Re: FRED Crashes
Post by: Bryan See on October 26, 2015, 01:57:52 pm: Running FRED2_OPEN AVX via MSVS2015 Community edition with all C++ and Win32 exceptions enabled at Exception Settings, it appears that everytime on startup, there is a parse error when attempting to open "armor.tbl" file, which is optionally required to exist while being built-in. It may be one of the causes FRED2_OPEN AVX crashing at various intervals, whether it is inactive or not. However, I do plan to test it more.

Call Stack:
Code: [Select]
> fred2_open_3_7_3_AVX-DEBUG.exe!read_raw_file_text(const char * filename, int mode, char * raw_text) Line 2117 C++ fred2_open_3_7_3_AVX-DEBUG.exe!read_file_text(const char * filename, int mode, char * processed_text, char * raw_text) Line 1987 C++ fred2_open_3_7_3_AVX-DEBUG.exe!armor_parse_table(const char * filename) Line 18325 C++ fred2_open_3_7_3_AVX-DEBUG.exe!armor_init() Line 18351 C++ fred2_open_3_7_3_AVX-DEBUG.exe!fred_init() Line 410 C++ fred2_open_3_7_3_AVX-DEBUG.exe!CFREDView::OnCreate(tagCREATESTRUCTA * lpCreateStruct) Line 4677 C++ fred2_open_3_7_3_AVX-DEBUG.exe!CWnd::OnWndMsg(unsigned int message, unsigned int wParam, long lParam, long * pResult) Line 2387 C++ fred2_open_3_7_3_AVX-DEBUG.exe!CWnd::WindowProc(unsigned int message, unsigned int wParam, long lParam) Line 2078 C++ fred2_open_3_7_3_AVX-DEBUG.exe!AfxCallWndProc(CWnd * pWnd, HWND__ * hWnd, unsigned int nMsg, unsigned int wParam, long lParam) Line 265 C++ fred2_open_3_7_3_AVX-DEBUG.exe!AfxWndProc(HWND__ * hWnd, unsigned int nMsg, unsigned int wParam, long lParam) Line 418 C++ [External Code] fred2_open_3_7_3_AVX-DEBUG.exe!CWnd::Create(const char * lpszClassName, const char * lpszWindowName, unsigned long dwStyle, const tagRECT & rect, CWnd * pParentWnd, unsigned int nID, CCreateContext * pContext) Line 785 C++ fred2_open_3_7_3_AVX-DEBUG.exe!CFrameWnd::CreateView(CCreateContext * pContext, unsigned int nID) Line 653 C++ fred2_open_3_7_3_AVX-DEBUG.exe!CFrameWnd::OnCreateClient(tagCREATESTRUCTA * __formal, CCreateContext * pContext) Line 675 C++ fred2_open_3_7_3_AVX-DEBUG.exe!CFrameWnd::OnCreateHelper(tagCREATESTRUCTA * lpcs, CCreateContext * pContext) Line 694 C++ fred2_open_3_7_3_AVX-DEBUG.exe!CFrameWnd::OnCreate(tagCREATESTRUCTA * lpcs) Line 686 C++ fred2_open_3_7_3_AVX-DEBUG.exe!CMainFrame::OnCreate(tagCREATESTRUCTA * lpCreateStruct) Line 108 C++ fred2_open_3_7_3_AVX-DEBUG.exe!CWnd::OnWndMsg(unsigned int message, unsigned int wParam, long lParam, long * pResult) Line 2387 C++ fred2_open_3_7_3_AVX-DEBUG.exe!CWnd::WindowProc(unsigned int message, unsigned int wParam, long lParam) Line 2078 C++ fred2_open_3_7_3_AVX-DEBUG.exe!AfxCallWndProc(CWnd * pWnd, HWND__ * hWnd, unsigned int nMsg, unsigned int wParam, long lParam) Line 265 C++ fred2_open_3_7_3_AVX-DEBUG.exe!AfxWndProc(HWND__ * hWnd, unsigned int nMsg, unsigned int wParam, long lParam) Line 418 C++ [External Code] fred2_open_3_7_3_AVX-DEBUG.exe!IsolationAwareCreateWindowExA(unsigned long dwExStyle, const char * lpClassName, const char * lpWindowName, unsigned long dwStyle, int X, int Y, int nWidth, int nHeight, HWND__ * hWndParent, HMENU__ * hMenu, HINSTANCE__ * hInstance, void * lpParam) Line 423 C++ fred2_open_3_7_3_AVX-DEBUG.exe!CWnd::CreateEx(unsigned long dwExStyle, const char * lpszClassName, const char * lpszWindowName, unsigned long dwStyle, int x, int y, int nWidth, int nHeight, HWND__ * hWndParent, HMENU__ * nIDorHMenu, void * lpParam) Line 724 C++ fred2_open_3_7_3_AVX-DEBUG.exe!CFrameWnd::Create(const char * lpszClassName, const char * lpszWindowName, unsigned long dwStyle, const tagRECT & rect, CWnd * pParentWnd, const char * lpszMenuName, unsigned long dwExStyle, CCreateContext * pContext) Line 622 C++ fred2_open_3_7_3_AVX-DEBUG.exe!CFrameWnd::LoadFrame(unsigned int nIDResource, unsigned long dwDefaultStyle, CWnd * pParentWnd, CCreateContext * pContext) Line 755 C++ fred2_open_3_7_3_AVX-DEBUG.exe!CDocTemplate::CreateNewFrame(CDocument * pDoc, CFrameWnd * pOther) Line 292 C++ fred2_open_3_7_3_AVX-DEBUG.exe!CSingleDocTemplate::OpenDocumentFile(const char * lpszPathName, int bAddToMRU, int bMakeVisible) Line 133 C++ fred2_open_3_7_3_AVX-DEBUG.exe!CSingleDocTemplate::OpenDocumentFile(const char * lpszPathName, int bMakeVisible) Line 83 C++ fred2_open_3_7_3_AVX-DEBUG.exe!CDocManager::OnFileNew() Line 912 C++ fred2_open_3_7_3_AVX-DEBUG.exe!CWinApp::OnFileNew() Line 21 C++ fred2_open_3_7_3_AVX-DEBUG.exe!CFREDApp::InitInstance() Line 259 C++ fred2_open_3_7_3_AVX-DEBUG.exe!AfxWinMain(HINSTANCE__ * hInstance, HINSTANCE__ * hPrevInstance, char * lpCmdLine, int nCmdShow) Line 37 C++ fred2_open_3_7_3_AVX-DEBUG.exe!WinMain(HINSTANCE__ * hInstance, HINSTANCE__ * hPrevInstance, char * lpCmdLine, int nCmdShow) Line 26 C++Autos:
Code: [Select]
+ filename 0x01201a48 "armor.tbl" const char * + mf 0x00000000 <NULL> CFILE *
Title: Re: FRED Crashes
Post by: m!m on October 26, 2015, 02:02:24 pm: Why have you enabled the C++ exception breakpoints? C++ exceptions are regularly thrown in the code without causing any issues. You only need to enable the Win32 breakpoints because those are needed when the executable crashes.
Title: Re: FRED Crashes
Post by: The E on October 26, 2015, 02:28:28 pm: And no, Bryan, a missing armor.tbl (or a missing scripting.html) will never, ever cause problems.
Title: Re: FRED Crashes
Post by: Bryan See on November 15, 2015, 09:46:06 pm: I've got an issue about ship subsystems when changing ship classes.

Code: [Select]
Assert: subsys_pcts[num_saved_subsystems] >= 0.0f && subsys_pcts[num_saved_subsystems] <= 1.0f File: ship.cpp Line: 10031 ntdll.dll! ZwWaitForSingleObject + 12 bytes KERNELBASE.dll! WaitForSingleObject + 18 bytes fred2_open_3_7_3_SSE2-DEBUG.exe! SCP_DumpStack + 354 bytes fred2_open_3_7_3_SSE2-DEBUG.exe! WinAssert + 194 bytes fred2_open_3_7_3_SSE2-DEBUG.exe! change_ship_type + 1281 bytes fred2_open_3_7_3_SSE2-DEBUG.exe! CShipEditorDlg::OnSelchangeShipClass + 161 bytes fred2_open_3_7_3_SSE2-DEBUG.exe! _AfxDispatchCmdMsg + 195 bytes fred2_open_3_7_3_SSE2-DEBUG.exe! CCmdTarget::OnCmdMsg + 858 bytes fred2_open_3_7_3_SSE2-DEBUG.exe! CDialog::OnCmdMsg + 66 bytes fred2_open_3_7_3_SSE2-DEBUG.exe! CWnd::OnCommand + 416 bytes fred2_open_3_7_3_SSE2-DEBUG.exe! CShipEditorDlg::OnCommand + 142 bytes fred2_open_3_7_3_SSE2-DEBUG.exe! CWnd::OnWndMsg + 134 bytes fred2_open_3_7_3_SSE2-DEBUG.exe! CWnd::WindowProc + 68 bytes fred2_open_3_7_3_SSE2-DEBUG.exe! AfxCallWndProc + 267 bytes fred2_open_3_7_3_SSE2-DEBUG.exe! AfxWndProc + 181 bytes USER32.dll! SetManipulationInputTarget + 83 bytes USER32.dll! CallWindowProcW + 768 bytes USER32.dll! DispatchMessageW + 1328 bytes USER32.dll! PeekMessageW + 1369 bytes ntdll.dll! KiUserCallbackDispatcher + 54 bytes USER32.dll! Ordinal1502 + 10560 bytes USER32.dll! Ordinal1502 + 6241 bytes USER32.dll! Ordinal1502 + 3354 bytes USER32.dll! Ordinal1502 + 987 bytes USER32.dll! SetManipulationInputTarget + 83 bytes USER32.dll! CallWindowProcW + 768 bytes USER32.dll! DispatchMessageW + 1328 bytes USER32.dll! PeekMessageW + 1369 bytes ntdll.dll! KiUserCallbackDispatcher + 54 bytes USER32.dll! SendMessageW + 323 bytes USER32.dll! DdeQueryStringW + 14891 bytes USER32.dll! Ordinal2573 + 1723 bytes USER32.dll! Ordinal2573 + 262 bytes USER32.dll! SetManipulationInputTarget + 83 bytes USER32.dll! CallWindowProcW + 768 bytes USER32.dll! DispatchMessageW + 593 bytes USER32.dll! DispatchMessageA + 16 bytes fred2_open_3_7_3_SSE2-DEBUG.exe! AfxInternalPumpMessage + 297 bytes fred2_open_3_7_3_SSE2-DEBUG.exe! CWinThread::PumpMessage + 19 bytes fred2_open_3_7_3_SSE2-DEBUG.exe! CWinThread::Run + 180 bytes fred2_open_3_7_3_SSE2-DEBUG.exe! CWinApp::Run + 108 bytes fred2_open_3_7_3_SSE2-DEBUG.exe! AfxWinMain + 308 bytes fred2_open_3_7_3_SSE2-DEBUG.exe! WinMain + 24 bytes fred2_open_3_7_3_SSE2-DEBUG.exe! invoke_main + 30 bytes fred2_open_3_7_3_SSE2-DEBUG.exe! __scrt_common_main_seh + 346 bytes fred2_open_3_7_3_SSE2-DEBUG.exe! __scrt_common_main + 13 bytes fred2_open_3_7_3_SSE2-DEBUG.exe! WinMainCRTStartup + 8 bytes KERNEL32.DLL! BaseThreadInitThunk + 36 bytes ntdll.dll! RtlUnicodeStringToInteger + 595 bytes ntdll.dll! RtlUnicodeStringToInteger + 542 bytes
Title: Re: FRED Crashes
Post by: herkie423 on November 17, 2015, 01:34:37 am: Quote from: AdmiralRalwood on October 20, 2015, 04:26:45 pm
Something has gone horribly wrong if "Arrival Location" is getting set to "Cable TV"; if I had to guess, the arrival_location is probably also -1, because an out-of-bounds array access is the only way I can think of for that string to get written there (and "Cable TV" is the last string of the previously-defined array). In fact, the "$Departure Anchor: <error>" is also only written if the departure_anchor is negative, so it sounds like an object with nothing but the default initialization values is getting saved for some reason.

I got this error in the last mission of "The Aftermath" - - - "wing out of bounds" I did not know what happen when it got saved by the FRED. But I managed to solved it by editing the mission file using notepad and replaced the "Cable TV" value with "hyperspace" (Default value) and setting the departure anchor to its proper value, 0. Then open the mission again in FRED and save. I suspect that this will happen if you have a lot ships in the Frey. The last mission in my campaign consist of one hundred fighter wings. All hell broke loose.
Title: Re: FRED Crashes
Post by: Bryan See on November 17, 2015, 01:32:49 pm: And I've got another issue, this time about deleting messages when the selected message is empty.

Code: [Select]
Assert: (m_cur_msg >= 0) && (m_cur_msg < m_num_messages) File: eventeditor.cpp Line: 1302 ntdll.dll! ZwWaitForSingleObject + 12 bytes KERNELBASE.dll! WaitForSingleObject + 18 bytes fred2_open_3_7_3_SSE2-DEBUG.exe! SCP_DumpStack + 354 bytes fred2_open_3_7_3_SSE2-DEBUG.exe! WinAssert + 194 bytes fred2_open_3_7_3_SSE2-DEBUG.exe! event_editor::OnDeleteMsg + 91 bytes fred2_open_3_7_3_SSE2-DEBUG.exe! _AfxDispatchCmdMsg + 195 bytes fred2_open_3_7_3_SSE2-DEBUG.exe! CCmdTarget::OnCmdMsg + 858 bytes fred2_open_3_7_3_SSE2-DEBUG.exe! CDialog::OnCmdMsg + 66 bytes fred2_open_3_7_3_SSE2-DEBUG.exe! CWnd::OnCommand + 416 bytes fred2_open_3_7_3_SSE2-DEBUG.exe! CWnd::OnWndMsg + 134 bytes fred2_open_3_7_3_SSE2-DEBUG.exe! CWnd::WindowProc + 68 bytes fred2_open_3_7_3_SSE2-DEBUG.exe! AfxCallWndProc + 267 bytes fred2_open_3_7_3_SSE2-DEBUG.exe! AfxWndProc + 181 bytes USER32.dll! SetManipulationInputTarget + 83 bytes USER32.dll! CallWindowProcW + 768 bytes USER32.dll! DispatchMessageW + 1328 bytes USER32.dll! PeekMessageW + 1369 bytes ntdll.dll! KiUserCallbackDispatcher + 54 bytes USER32.dll! SendMessageW + 323 bytes USER32.dll! LoadCursorFromFileW + 16683 bytes USER32.dll! LoadCursorFromFileW + 15288 bytes USER32.dll! LoadCursorFromFileW + 8738 bytes USER32.dll! LoadCursorFromFileW + 5842 bytes USER32.dll! SetManipulationInputTarget + 83 bytes USER32.dll! CallWindowProcW + 768 bytes USER32.dll! DispatchMessageW + 593 bytes USER32.dll! IsDialogMessageW + 235 bytes USER32.dll! IsDialogMessage + 78 bytes fred2_open_3_7_3_SSE2-DEBUG.exe! CWnd::IsDialogMessageA + 148 bytes fred2_open_3_7_3_SSE2-DEBUG.exe! CWnd::PreTranslateInput + 125 bytes fred2_open_3_7_3_SSE2-DEBUG.exe! CDialog::PreTranslateMessage + 297 bytes fred2_open_3_7_3_SSE2-DEBUG.exe! CWnd::WalkPreTranslateTree + 174 bytes fred2_open_3_7_3_SSE2-DEBUG.exe! AfxInternalPreTranslateMessage + 99 bytes fred2_open_3_7_3_SSE2-DEBUG.exe! CWinThread::PreTranslateMessage + 42 bytes fred2_open_3_7_3_SSE2-DEBUG.exe! AfxPreTranslateMessage + 45 bytes fred2_open_3_7_3_SSE2-DEBUG.exe! AfxInternalPumpMessage + 253 bytes fred2_open_3_7_3_SSE2-DEBUG.exe! CWinThread::PumpMessage + 19 bytes fred2_open_3_7_3_SSE2-DEBUG.exe! CWinThread::Run + 180 bytes fred2_open_3_7_3_SSE2-DEBUG.exe! CWinApp::Run + 108 bytes fred2_open_3_7_3_SSE2-DEBUG.exe! AfxWinMain + 308 bytes fred2_open_3_7_3_SSE2-DEBUG.exe! WinMain + 24 bytes fred2_open_3_7_3_SSE2-DEBUG.exe! invoke_main + 30 bytes fred2_open_3_7_3_SSE2-DEBUG.exe! __scrt_common_main_seh + 346 bytes fred2_open_3_7_3_SSE2-DEBUG.exe! __scrt_common_main + 13 bytes fred2_open_3_7_3_SSE2-DEBUG.exe! WinMainCRTStartup + 8 bytes KERNEL32.DLL! BaseThreadInitThunk + 36 bytes ntdll.dll! RtlUnicodeStringToInteger + 595 bytes ntdll.dll! RtlUnicodeStringToInteger + 542 bytes
Title: Re: FRED Crashes
Post by: AdmiralRalwood on November 17, 2015, 04:20:39 pm: Quote from: Bryan See on November 17, 2015, 01:32:49 pm
And I've got another issue, this time about deleting messages when the selected message is empty.

Code: [Select]
Assert: (m_cur_msg >= 0) && (m_cur_msg < m_num_messages) File: eventeditor.cpp Line: 1302
It looks like the code allows this function to be called when m_cur_msg is -1 (meaning there are no messages defined by the mission), making this assertion incorrect (should probably be >= -1 instead). Obvious workaround while waiting for the PR: don't try to delete a message when there's no message to delete in a Debug build. ;)
Title: Re: FRED Crashes
Post by: Bryan See on November 19, 2015, 11:29:51 am: I think the solution is when there are no messages in the mission or there are no messages selected, the delete button must be greyed out.
Title: Re: FRED Crashes
Post by: The E on November 19, 2015, 11:37:50 am: This error has been fixed here: https://github.com/scp-fs2open/fs2open.github.com/pull/447
Title: Re: FRED Crashes
Post by: Bryan See on November 21, 2015, 11:59:25 am: Thanks, The E for this.

Quote from: herkie423 on November 17, 2015, 01:34:37 am
Quote from: AdmiralRalwood on October 20, 2015, 04:26:45 pm
Something has gone horribly wrong if "Arrival Location" is getting set to "Cable TV"; if I had to guess, the arrival_location is probably also -1, because an out-of-bounds array access is the only way I can think of for that string to get written there (and "Cable TV" is the last string of the previously-defined array). In fact, the "$Departure Anchor: <error>" is also only written if the departure_anchor is negative, so it sounds like an object with nothing but the default initialization values is getting saved for some reason.

I got this error in the last mission of "The Aftermath" - - - "wing out of bounds" I did not know what happen when it got saved by the FRED. But I managed to solved it by editing the mission file using notepad and replaced the "Cable TV" value with "hyperspace" (Default value) and setting the departure anchor to its proper value, 0. Then open the mission again in FRED and save. I suspect that this will happen if you have a lot ships in the Frey. The last mission in my campaign consist of one hundred fighter wings. All hell broke loose.

Are there any solution to this?
Title: Re: FRED Crashes
Post by: The E on November 21, 2015, 12:05:48 pm: No, because we do not have enough info at this time to reproduce and fix that issue.
Title: Re: FRED Crashes
Post by: Black-Sheep on December 04, 2015, 03:42:49 pm: Hello,

i am quite new to fred.

however i tryed version 3.7.3 SSE2 (as intel i-Core) and the standard versions.

Both don't start :(
no error nothing, just the "busy" mouse pointer.

Using Windows 10, 64-Bit, tryed to run as Administrator and with Win7 Compatibility mode.
Nothing works.

any suggestions?
Title: Re: FRED Crashes
Post by: Goober5000 on December 04, 2015, 06:43:53 pm: Does FreeSpace have the same problem?

Please post your fred2_open.log file. Instructions on how to do this can be found in this post. (The procedure is the same for fs2_open.log and fred2_open.log, except for the name.)
Title: Re: FRED Crashes
Post by: Black-Sheep on December 05, 2015, 02:29:38 pm: Thanks for the Reply,

Freespace 2 runs BluePlanet Complete von the 3.7.3.exe no Problem, crash or anything with it - it just loads normaly and runs perfectly.

FRED however does not do anything at all. Nada.
It doesn't even crash.

While i do have a "busy" mouse icon (the Blue circle of windows next to the mouse) after trying to start it, it never actually starts.
There is not even a TASK to be observed while it try to start it.
As it's not starting it's alsow not crashing - the result is a not existend log file :(

i double checked - but no, i don't have a fred2_open.log file on my PC

i know this sounds totaly strange and - while beeing a certified microsoft Admin - i can tell you this is indeed strange.... there is no IO whatsover... Windows Eventlog is empty too....

is it possible that FRED needs somekind of .NET framework Freespace alone does not need? (maybe windows 10 is missing a few librarys?)
Title: Re: FRED Crashes
Post by: niffiwan on December 05, 2015, 06:41:35 pm: I've heard of cases where the AV has done something to FSO that stops it running, perhaps on your PC it's done something similar to FRED?