Bug 948074

Created attachment 731421 [details]
File: backtrace

Created attachment 731422 [details]
File: cgroup

Created attachment 731423 [details]
File: core_backtrace

Created attachment 731424 [details]
File: dso_list

Created attachment 731425 [details]
File: environ

Created attachment 731426 [details]
File: limits

Created attachment 731427 [details]
File: maps

Created attachment 731428 [details]
File: open_fds

Created attachment 731429 [details]
File: proc_pid_status

Created attachment 731430 [details]
File: smolt_data

Created attachment 731431 [details]
File: var_log_messages

Hmmm, this might be due to my patches to make native 64-bit builds of the host parts of NSIS possible. I'll have a look ASAP to see what could be wrong.

Yeah, at least those m_dwWrittenAt variables need to be changed from DWORD to long too, they're used to store host pointers.

This could be of interest:
https://bitbucket.org/dgolub/nsis64
They target W64, which means they probably have fixes for the stuff I fixed and also for the stuff I missed, and they probably also have 64-bit TARGET support working, which I didn't even attempt, so we should be able build a mingw64-nsis package from that. But I haven't tried it yet, so I don't know whether they haven't broken POSIX host support or some other thing we need.

Actually, this particular issue was fixed upstream (in the official NSIS, not the nsis64 fork) as part of:
http://nsis.svn.sourceforge.net/viewvc/nsis?view=revision&revision=6040

I'm still working on this. I don't want to apply revision 6040 as is because:
* it contains unrelated changes (countof, Unicode/tchar.h) and
* it does not contain this change:
@@ -703,7 +703,7 @@
   WORD e_oemid;
   WORD e_oeminfo;
   WORD e_res2[10];
-  LONG e_lfanew;
+  DWORD e_lfanew;
 } IMAGE_DOS_HEADER,*PIMAGE_DOS_HEADER;
 #  pragma pack()
 #  pragma pack(4)
which I'm fairly sure is needed. IMAGE_DOS_HEADER is a standard structure which is even getting defined up to packing, having e_lfanew be a different size on different hosts sounds like a very bad idea to me.

BTW, a recent upstream commit:
http://nsis.svn.sourceforge.net/viewvc/nsis?view=revision&revision=6321
changes DWORD to be unsigned long, which looks even more broken to me, I doubt that commit was even tested at all on an LP64 platform.

*** Bug 967932 has been marked as a duplicate of this bug. ***

Whoops, I dropped the ball on this one, I'll have another look ASAP.

*** Bug 1026320 has been marked as a duplicate of this bug. ***

According to the LLVM source DWORD would be correct for e_lfanew..  (reference: http://llvm.org/docs/doxygen/html/Object_2COFF_8h_source.html ).

...time passes...

Actually I wend through and debugged the binary and located the issue and have it fixed!

it's REALLY super simple too..

on line 757 of ResourceEditor.cpp the cRDataE->m_dwWrittenAt member is cast as a pointer of a struct.     However..  m_dwWrittenAt is a DWORD (32bits) thus it fails....  horribly...  resulting in this segfault.

This patch fixes the issue..

--- ResourceEditor.h.64bit	2009-02-01 09:44:30.000000000 -0500
+++ ResourceEditor.h	2014-07-23 17:12:20.000000000 -0400
@@ -180,7 +180,7 @@
 
   void Destroy();
 
-  DWORD m_dwWrittenAt;
+  long m_dwWrittenAt;
 
 private:
   IMAGE_RESOURCE_DIRECTORY m_rdDir;
@@ -204,7 +204,7 @@
 
   CResourceDataEntry* GetDataEntry();
 
-  DWORD m_dwWrittenAt;
+  long m_dwWrittenAt;
 
 private:
   bool m_bHasName;
@@ -232,7 +232,7 @@
   DWORD GetCodePage();
   DWORD GetOffset();
 
-  DWORD m_dwWrittenAt;
+  long m_dwWrittenAt;
 
 private:
   BYTE* m_pbData;

Created attachment 922639 [details]
Patch to fix crash in 64bit build of makensis

This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

This is still an issue in F21/rawhide.. and the patch I attached last will fix the issue.

I just met this problem with mingw32-nsis-2.46-15.fc22.x86_64 and mingw32-nsis-2.46-16.fc23.x86_64. I can confirm that the patch provided by Edward Rudd fixes the issue.