Please ignore the problem. 
I must had had an old file somewhere interfering with the build. 
I started everything again from scratch and had no problems.


----- Original Message -----
> From: Alejandro Salas <[email protected]>
> To: eList <[email protected]>
> Cc: 
> Sent: Tuesday, September 10, 2013 9:58 PM
> Subject: Re: [e-users] Segmentation fault compiling 0.17.4
> 
>>  That line doesn't help much. You need to call the same command line
>>  from enlightenment src/modules subdirectory and prefix it with
>>  valgrind. Then send us the output result.
> 
> Thank you, here's the valgrind output
> 
> 
> valgrind /opt/efl/bin/edje_cc -DLOWRES_PDA=1 -DMEDIUMRES_PDA=2 -DHIRES_PDA=3 
> -DSLOW_PC=4 -DMEDIUM_PC=5 -DFAST_PC=6 -DE17_PROFILE=SLOW_PC -id 
> ./tiling/images 
> tiling/e-module-tiling.edc tiling/e-module-tiling.edj
> ==30779== Memcheck, a memory error detector
> ==30779== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
> ==30779== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
> ==30779== Command: /opt/efl/bin/edje_cc -DLOWRES_PDA=1 -DMEDIUMRES_PDA=2 
> -DHIRES_PDA=3 -DSLOW_PC=4 -DMEDIUM_PC=5 -DFAST_PC=6 -DE17_PROFILE=SLOW_PC -id 
> ./tiling/images tiling/e-module-tiling.edc tiling/e-module-tiling.edj
> ==30779==
> ==30779== Invalid read of size 1
> ==30779==    at 0x480E550: _eet_hash_gen (in /opt/efl/lib/libeet.so.1.7.99)
> ==30779==    by 0x4803FCA: eet_dictionary_string_add (in 
> /opt/efl/lib/libeet.so.1.7.99)
> ==30779==    by 0x47FB6B7: eet_data_put_string (in 
> /opt/efl/lib/libeet.so.1.7.99)
> ==30779==    by 0x47FC5F6: eet_data_put_type (in 
> /opt/efl/lib/libeet.so.1.7.99)
> ==30779==    by 0x4802B9A: eet_data_put_unknown (in 
> /opt/efl/lib/libeet.so.1.7.99)
> ==30779==    by 0x4803651: _eet_data_descriptor_encode (in 
> /opt/efl/lib/libeet.so.1.7.99)
> ==30779==    by 0x4802BD7: eet_data_put_unknown (in 
> /opt/efl/lib/libeet.so.1.7.99)
> ==30779==    by 0x4803651: _eet_data_descriptor_encode (in 
> /opt/efl/lib/libeet.so.1.7.99)
> ==30779==    by 0x4802A98: eet_data_put_array (in 
> /opt/efl/lib/libeet.so.1.7.99)
> ==30779==    by 0x4803651: _eet_data_descriptor_encode (in 
> /opt/efl/lib/libeet.so.1.7.99)
> ==30779==    by 0x47FDE60: eet_data_write_cipher (in 
> /opt/efl/lib/libeet.so.1.7.99)
> ==30779==    by 0x47FDEF6: eet_data_write (in /opt/efl/lib/libeet.so.1.7.99)
> ==30779==  Address 0xffffffff is not stack'd, malloc'd or (recently) 
> free'd
> ==30779==
> ==30779==
> ==30779== Process terminating with default action of signal 11 (SIGSEGV)
> ==30779==  Access not within mapped region at address 0xFFFFFFFF
> ==30779==    at 0x480E550: _eet_hash_gen (in /opt/efl/lib/libeet.so.1.7.99)
> ==30779==    by 0x4803FCA: eet_dictionary_string_add (in 
> /opt/efl/lib/libeet.so.1.7.99)
> ==30779==    by 0x47FB6B7: eet_data_put_string (in 
> /opt/efl/lib/libeet.so.1.7.99)
> ==30779==    by 0x47FC5F6: eet_data_put_type (in 
> /opt/efl/lib/libeet.so.1.7.99)
> ==30779==    by 0x4802B9A: eet_data_put_unknown (in 
> /opt/efl/lib/libeet.so.1.7.99)
> ==30779==    by 0x4803651: _eet_data_descriptor_encode (in 
> /opt/efl/lib/libeet.so.1.7.99)
> ==30779==    by 0x4802BD7: eet_data_put_unknown (in 
> /opt/efl/lib/libeet.so.1.7.99)
> ==30779==    by 0x4803651: _eet_data_descriptor_encode (in 
> /opt/efl/lib/libeet.so.1.7.99)
> ==30779==    by 0x4802A98: eet_data_put_array (in 
> /opt/efl/lib/libeet.so.1.7.99)
> ==30779==    by 0x4803651: _eet_data_descriptor_encode (in 
> /opt/efl/lib/libeet.so.1.7.99)
> ==30779==    by 0x47FDE60: eet_data_write_cipher (in 
> /opt/efl/lib/libeet.so.1.7.99)
> ==30779==    by 0x47FDEF6: eet_data_write (in /opt/efl/lib/libeet.so.1.7.99)
> ==30779==  If you believe this happened as a result of a stack
> ==30779==  overflow in your program's main thread (unlikely but
> ==30779==  possible), you can try to increase the size of the
> ==30779==  main thread stack using the --main-stacksize= flag.
> ==30779==  The main thread stack size used in this run was 8388608.
> ==30779==
> ==30779== HEAP SUMMARY:
> ==30779==     in use at exit: 439,388 bytes in 5,595 blocks
> ==30779==   total heap usage: 25,220 allocs, 19,625 frees, 2,523,610 bytes 
> allocated
> ==30779==
> ==30779== LEAK SUMMARY:
> ==30779==    definitely lost: 0 bytes in 0 blocks
> ==30779==    indirectly lost: 0 bytes in 0 blocks
> ==30779==      possibly lost: 0 bytes in 0 blocks
> ==30779==    still reachable: 439,388 bytes in 5,595 blocks
> ==30779==         suppressed: 0 bytes in 0 blocks
> ==30779== Rerun with --leak-check=full to see details of leaked memory
> ==30779==
> ==30779== For counts of detected and suppressed errors, rerun with: -v
> ==30779== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
> Segmentation fault
> 
> ------------------------------------------------------------------------------
> How ServiceNow helps IT people transform IT departments:
> 1. Consolidate legacy IT systems to a single system of record for IT
> 2. Standardize and globalize service processes across IT
> 3. Implement zero-touch automation to replace manual, redundant tasks
> http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg.clktrk
> _______________________________________________
> enlightenment-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/enlightenment-users
> 

------------------------------------------------------------------------------
How ServiceNow helps IT people transform IT departments:
1. Consolidate legacy IT systems to a single system of record for IT
2. Standardize and globalize service processes across IT
3. Implement zero-touch automation to replace manual, redundant tasks
http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg.clktrk
_______________________________________________
enlightenment-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-users

Reply via email to