I'm seeing the same thing on sepolicy-analyze. On Sun, Nov 23, 2014 at 11:59 AM, William Roberts <[email protected]> wrote: > I am using the current master of check-seapp and I am getting a > segfault and valgrind is outputting this: > > > $ valgrind ./sepolicy-check -s system_app -t system_data_file -c file > -p write -P /home/bill/workspace/udoo/out/target/product/udoo/root/sepolicy > ==6300== Memcheck, a memory error detector > ==6300== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. > ==6300== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info > ==6300== Command: ./sepolicy-check -s system_app -t system_data_file > -c file -p write -P > /home/bill/workspace/udoo/out/target/product/udoo/root/sepolicy > ==6300== > ==6300== Invalid read of size 4 > ==6300== at 0x804D5C8: expand_avtab_node (expand.c:3137) > ==6300== by 0x8049FC6: avtab_map (avtab.c:285) > ==6300== by 0xFEF27EF3: ??? > ==6300== Address 0x8 is not stack'd, malloc'd or (recently) free'd > ==6300== > ==6300== > ==6300== Process terminating with default action of signal 11 (SIGSEGV) > ==6300== Access not within mapped region at address 0x8 > ==6300== at 0x804D5C8: expand_avtab_node (expand.c:3137) > ==6300== by 0x8049FC6: avtab_map (avtab.c:285) > ==6300== by 0xFEF27EF3: ??? > ==6300== If you believe this happened as a result of a stack > ==6300== overflow in your program's main thread (unlikely but > ==6300== possible), you can try to increase the size of the > ==6300== main thread stack using the --main-stacksize= flag. > > > Attached is my binary sepolicy which is an OLD version 23 policy. I > didn't see the quick fix, so punting to you guys. > > -- > Respectfully, > > William C Roberts
-- Respectfully, William C Roberts _______________________________________________ Seandroid-list mailing list [email protected] To unsubscribe, send email to [email protected]. To get help, send an email containing "help" to [email protected].
