[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-dev] Building Tor Browser Bundle on Windows



On 3/4/2013 7:08 PM, Mike Perry wrote:
>> 1) Firefox's official build environment is VS2010 while TBB's is
>> VS2008
>>
>> I'm not 100% sure, but it seems like it'd be relatively easy to switch
>> TBB over to 2010.  There may be some issues.  But it seems like it'd
>> be good to track FF's official build env.  I ran across at least 1
>> Vanilla FF issue that broke in 2008, and there seemed to be a few in
>> the bugtracker.
> 
> I think this is a good idea too. I'm trying to track bugs that are
> toolchain-related under
> https://trac.torproject.org/projects/tor/ticket/8401. I've found at
> least 3 so far, and they are all very subtle and irritatingly time
> consuming to diagnose. We should just standardize on whatever Mozilla
> builds with.

I will work on matching to Mozilla's and track individual items in subtickets.


>> 2) Vidalia's build environment instructions contradict TBB's
>>
>> https://gitweb.torproject.org/vidalia.git/blob/HEAD:/INSTALL
>> https://gitweb.torproject.org/torbrowser.git/blob/HEAD:/docs/buildmachine_setups/windows.txt
>>
>> Vidalia's says you need CMake in your PATH, TBB's says you don't.  I
>> think it can be in your PATH.
> 
> This is interesting. My attempt to build on windows failed due to CMake
> not finding CMAKE_ROOT.

It complained when you had CMake in your path, or when you didn't?  Something I got tripped up by was building in a MinGW prompt vs a normal command prompt.  In my "simplest reproduction" phase, I found I could build straight from a windows command prompt if CMake was in my path.


>> Finally, after all this.... tbb-firefox crashes. I don't know why.  I
>> don't know if it's because I'm using VS2010, or my msvc*.dll swaps.
>>
>> I'm not quite sure where to start figuring out *why* it's
>> dereferencing a null ptr.  The windbg output is in the bottom of both
>> docs.
> 
> We've got a null pointer dereference in
> https://trac.torproject.org/projects/tor/ticket/8324. Could be what
> you're seeing, if you're somehow triggering drag+drop? I pushed a fix to
> torbrowser.git, but it also requires a Torbutton update to allow
> Drag+Drop again. I think the patch update should at least stop that
> crash, though.


Hm.  I'll see if I can find time to test more tomorrow: that crash is in xul.dll!JSD_GetValueForObject whereas mine is in xul!ReteNodeSet::Iterator::operator*+0xa

Also, mine occurs on startup, I can't even get the browser loaded enough to see the application.

-tom
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev