Re: [igraph] Building igraph 0.6 rev 1601 with msvc9

[Chris Wj]

Chris,

I remember having this at some point of time, but only for the
non-debug builds (or the other way?). So try the debug build if you
used the non-debug one, or the opposite way.

We should really look into this, but the thing is that I am not very
comfortable with debugging windows applications, so I am sure that I
would do it until finalizing the 0.6 release.

Btw. why do you need to rebuild libxml2? Is the pre-built binary not
good enough?

Actually, I first used the pre-built binary, and when it crashed the first time, I thought it was because it was built using a different compiler. I used msvc90 (from VS 2008), so I rebuilt the latest libxml2 2.7.3 with that compiler. It depends on iconv, which doesn't come with a way to build using msvc, so I still used the prebuilt binary of iconv when building libxml2.

Hi Chris,

Hmm, I'm not very familiar with Windows debugging either. Can you obtain
a full stack dump somehow at the point where the application crashed?

It is 13MB compressed (7zip). Send it to you directly?
 

Does it also happen with graph or edge attributes? Are you sure that
your application is loading the rebuilt libxml2 instead of the original
one? (It can cause problems when you use one version of a DLL when
_building_ the app and another one when _running_ it, especially if the
ABI changed in the meanwhile).

--
Tamas

Hmm, I pointed it to the new libxml2 when building, and it built igraph.lib (static), so I thought I was all good there. I will restrict the path and do some more testing to make sure that it is using all the correct dlls.

C:\Users\wj>python
Python 2.6.2 (r262:71605, Apr 14 2009, 22:40:02) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import igraph
>>> G = igraph.Graph(5)
>>> G.add_edges([(0,1),(0,3),(3,4),(1,4)])
<igraph.Graph object at 0x021CB1C8>
>>> G['graphattr1']="graphvalue1"
>>> G.write("C:/Users/wj/Desktop/graphattr.graphml")
>>> G2 = igraph.Graph(5)
>>> G2.add_edges([(0,1),(0,3),(3,4),(1,4)])
<igraph.Graph object at 0x021CB250>
>>> G2.es['edgeattr1']=["edgevalue%s"%i for i in range(0,G2.ecount())]
>>> G2.write("C:/Users/wj/Desktop/edgeattrs.graphml")
>>> G3 = igraph.read("C:/Users/nrl/Desktop/graphattr.graphml")
{ CRASH }

Unhandled exception at 0x7785759d in python.exe: 0xC0000005: Access violation reading location 0x01f91708.

Call Stack:
>    ntdll.dll!7785759d()    
     [Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]   
     ntdll.dll!7785730a()    
     msvcr90.dll!6f2a38bb()    
     kernel32.dll!75f49a26()    
     msvcr90.dll!6f2a38bb()    
     msvcr90.dll!6f270366()    
     python26.dll!1e017ab1()    
     python26.dll!1e01eb8e()    
     python26.dll!1e0133cf()    
     python26.dll!1e010d77()    
     python26.dll!1e00e4b7()    
     python26.dll!1e0110cb()    
     python26.dll!1e00e4b7()    
     python26.dll!1e016303()    
     python26.dll!1e011771()    
     python26.dll!1e0110cb()    
     python26.dll!1e00e4b7()    
     python26.dll!1e011333()    
     python26.dll!1e0126a8()    
     python26.dll!1e01a75d()    
     python26.dll!1e0b3858()    
     kernel32.dll!75f49a26()    
     msvcr90.dll!6f2a38bb()    
     python26.dll!1e02b629()    
     python26.dll!1e02c4a5()    
     python26.dll!1e00a9b4()    
     python26.dll!1e0133cf()    
     python26.dll!1e0196ac()    
     python26.dll!1e013c8d()    
     python26.dll!1e00e7d7()    
     python26.dll!1e0133cf()    
     python26.dll!1e01415e()    
     python26.dll!1e00f867()    
     python26.dll!1e011317()    
     python26.dll!1e0135b3()    
     python26.dll!1e01415e()    
     python26.dll!1e00f867()    
     python26.dll!1e011317()    
     python26.dll!1e010d42()    
     python26.dll!1e00e4b7()    
     python26.dll!1e011317()    
     python26.dll!1e0266ff()    
     python26.dll!1e023492()    
     python26.dll!1e0218e2()    
     python.exe!1d00103c()    
     msvcr90.dll!6f262201()    
     python.exe!1d001160()    
     kernel32.dll!75f4d0e9()    
     ntdll.dll!778319bb()    
     ntdll.dll!7783198e()    

...
77857583  test        cl,1
77857586  je          77857EEB
7785758C  cmp         dword ptr [ebx+4Ch],0
77857590  mov         eax,dword ptr [ebp+10h]
77857593  mov         eax,dword ptr [eax]
77857595  lea         esi,[edi+eax*8]
77857598  mov         dword ptr [ebp+0Ch],esi
7785759B  je          778575BA
> 7785759D  mov         eax,dword ptr [esi]
7785759F  mov         dword ptr [ebp-1Ch],eax
778575A2  xor         eax,dword ptr [ebx+50h]
778575A5  mov         cl,al
778575A7  xor         cl,ah
778575A9  mov         dword ptr [ebp-1Ch],eax
778575AC  xor         cl,byte ptr [ebp-1Ah]
778575AF  shr         eax,18h
778575B2  cmp         al,cl
778575B4  jne         7786B197
778575BA  mov         eax,dword ptr [ebx+4Ch]
778575BD  shr         eax,14h
778575C0  and         al,byte ptr [ebx+52h]
778575C3  xor         al,byte ptr [esi+2]
778575C6  test        al,1
...

And the edge attrs crashed too:
>>> import igraph
>>> G4 = igraph.read("C:/Users/nrl/Desktop/edgeattrs.graphml")

On Tue, Aug 4, 2009 at 2:01 AM, Chris Wj<address@hidden> wrote:
> Hmm. It seems like this is a problem with reading any graphml with custom
> attributes. I can read and write simple graphs in graphml and gml. It always
> fails when I read a file with vertex attributes.
>
> What I did was generate a graph, give it vertex attributes, write it to
> disk, and then try to read it back in from the file.
>
> On Mon, Aug 3, 2009 at 7:51 PM, Chris Wj <address@hidden> wrote:
>>
>> After rebuilding with libxml2, the igraph.Graph.Read_GraphML (Python) call
>> results in an application crash.
>>
>> I get an "Access violation reading location ..." in ntdll.dll
>>
>> I rebuilt libxml2 from scratch with msvc9 first.
>>
>> And I was so close... other things seem to be working as I can create
>> graphs and whatnot.
>>
>>
>> On Mon, Aug 3, 2009 at 4:14 PM, Chris Wj <address@hidden> wrote:
>>>
>>> I added #include "igraph_math.h" to foreign-ncol-parser.c,
>>> foreign-lgl-parser.c, bliss_bignum.hh, and centrality.c
>>>
>>> Also added the definition for igraph_i_snprintf under the
>>> '#ifdef _MSC_VER' and after  '#define snprintf igraph_i_snprintf'
>>>
>>> All dependencies resolved... NICE!
>>>
>>> On Sat, Aug 1, 2009 at 9:23 PM, Chris Wj <address@hidden> wrote:
>>>>
>>>> Ok I spoke too soon.
>>>>
>>>> From: http://msdn.microsoft.com/en-us/library/cx3b23a3(VS.80).aspx
>>>>
>>>> C Language Reference
>>>> Inline Functions
>>>>
>>>> Microsoft Specific
>>>>
>>>> The __inline keyword tells the compiler to substitute the code within
>>>> the function definition for every instance of a function call. However,
>>>> substitution occurs only at the compiler's discretion. For example, the
>>>> compiler does not inline a function if its address is taken or if it is too
>>>> large to inline.
>>>>
>>>> For a function to be considered as a candidate for inlining, it must use
>>>> the new-style function definition.
>>>>
>>>> Just make sure that jives with what you want, especially that "at the
>>>> compiler's discretion" part.
>>>>
>>>> On Sat, Aug 1, 2009 at 9:20 PM, Chris Wj <address@hidden> wrote:
>>>>>
>>>>> From http://msdn.microsoft.com/en-us/library/z8y1yy88(VS.80).aspx
>>>>>
>>>>> The inline keyword is available only in C++. The __inline and
>>>>> __forceinline keywords are available in both C and C++. For compatibility
>>>>> with previous versions, _inline is a synonym for __inline.
>>>>>
>>>>> That's the C++ documentation. They don't even mention __inline in the C
>>>>> documentation part.
>>>>>
>>>>> On Sat, Aug 1, 2009 at 9:12 PM, Chris Wj <address@hidden> wrote:
>>>>>>
>>>>>> Thanks for the updates Tamas, they will help out. There were a few
>>>>>> other files missing from the msvc project that I added. They were relatively
>>>>>> easy to pick out through trial and error though. I'll post/upload the
>>>>>> project file when I have the last unresolved symbol figured out.
>>>>>>
>>>>>> Yeah, while inline is a C99 standard keyword it seems like in MSVC
>>>>>> only C++ recognizes inline, but C recognizes __inline. After a quick web
>>>>>> search, it looks like many others had this issue too. They basically did the
>>>>>> same thing you did to redefine inline to __inline. I'd still like to know
>>>>>> why!
>>>>>>
>>>>>> On Sat, Aug 1, 2009 at 4:11 PM, Tamas Nepusz <address@hidden> wrote:
>>>>>>>>
>>>>>>>> Hi guys. I just built igraph 0.6 from bzr rev 1601 on Windows with
>>>>>>>> msvc9 (VS 2008). I had to make changes in 2 files:
>>>>>>>
>>>>>>> Fixed as well -- added M_SQRT2 to igraph_math.h and included it from
>>>>>>> src/centrality.c. I'm not sure about the inline stuff -- I thought that
>>>>>>> inline is a valid C keyword, but it looks like we have to live with a
>>>>>>> compiler-related hack here. Something like:
>>>>>>>
>>>>>>> #if defined(_MSC_VER)
>>>>>>> #  define inline __inline
>>>>>>> #endif
>>>>>>>
>>>>>>> I added the above code snippet to src/heap.c, hope this helps.
>>>>>>>
>>>>>>> --
>>>>>>> Tamas
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> igraph-help mailing list
>>>>>>> address@hidden
>>>>>>> http://lists.nongnu.org/mailman/listinfo/igraph-help
>>>>>>
>>>>>
>>>>
>>>
>>
>
>
> _______________________________________________
> igraph-help mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/igraph-help
>
>

--

Gabor Csardi <address@hidden>     UNIL DGM


_______________________________________________

igraph-help mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/igraph-help