Cannot access memory (task-manager.cc)

[mateus....@gmail.com]

Hello,

If anyone has any ideia about a fix for the following error, please let me know. 

I would appreciate any comments. tks!

Program received signal SIGSEGV, Segmentation fault.

0x00007ffff7ac6ce8 in ns3::TaskManager::CurrentTask (this=0x0)

    at ../model/task-manager.cc:393

393  if (m_hightask)

(gdb) frame 0

#0  0x00007ffff7ac6ce8 in ns3::TaskManager::CurrentTask (this=0x0)

    at ../model/task-manager.cc:393

393  if (m_hightask)

(gdb) print m_hightask

Cannot access memory at address 0x28

(gdb) 

[mateus....@gmail.com]

Adding the valgrind output in case anyone wants to collaborate on this. 

Any comments are welcome.

Thanks!

==6685== Memcheck, a memory error detector

==6685== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.

==6685== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info

==6685== Command: ./build/bin/dce-ovs

==6685== 

==6685== Warning: client syscall munmap tried to modify addresses 0xffffffffffffffff-0x3f3ffe

==6685== Invalid read of size 8

==6685==    at 0x4FEACE8: ns3::TaskManager::CurrentTask() (task-manager.cc:393)

==6685==    by 0x50659EE: ns3::KernelSocketFdFactory::TaskCurrent(SimKernel*) (kernel-socket-fd-factory.cc:331)

==6685==    by 0xFCA2788: ??? (in /disk/bake/source/ns-3-dce/elf-cache/0/liblinux.so)

==6685==    by 0x7FEFFE76F: ???

==6685==    by 0xFCA2798: ??? (in /disk/bake/source/ns-3-dce/elf-cache/0/liblinux.so)

==6685==    by 0x2E90EDCFFF: ???

==6685==    by 0xFCD58F8: ??? (in /disk/bake/source/ns-3-dce/elf-cache/0/liblinux.so)

==6685==    by 0x12D94E4F: ???

==6685==    by 0xFD23D20: ??? (in /disk/bake/source/ns-3-dce/elf-cache/0/liblinux.so)

==6685==    by 0x2E90EDCFFF: ???

==6685==    by 0x12D94E4F: ???

==6685==    by 0x13B4AC0F: ???

==6685==  Address 0x28 is not stack'd, malloc'd or (recently) free'd

==6685== 

==6685== 

==6685== Process terminating with default action of signal 11 (SIGSEGV)

==6685==  Access not within mapped region at address 0x28

==6685==    at 0x4FEACE8: ns3::TaskManager::CurrentTask() (task-manager.cc:393)

==6685==    by 0x50659EE: ns3::KernelSocketFdFactory::TaskCurrent(SimKernel*) (kernel-socket-fd-factory.cc:331)

==6685==    by 0xFCA2788: ??? (in /disk/bake/source/ns-3-dce/elf-cache/0/liblinux.so)

==6685==    by 0x7FEFFE76F: ???

==6685==    by 0xFCA2798: ??? (in /disk/bake/source/ns-3-dce/elf-cache/0/liblinux.so)

==6685==    by 0x2E90EDCFFF: ???

==6685==    by 0xFCD58F8: ??? (in /disk/bake/source/ns-3-dce/elf-cache/0/liblinux.so)

==6685==    by 0x12D94E4F: ???

==6685==    by 0xFD23D20: ??? (in /disk/bake/source/ns-3-dce/elf-cache/0/liblinux.so)

==6685==    by 0x2E90EDCFFF: ???

==6685==    by 0x12D94E4F: ???

==6685==    by 0x13B4AC0F: ???

==6685==  If you believe this happened as a result of a stack

==6685==  overflow in your program's main thread (unlikely but

==6685==  possible), you can try to increase the size of the

==6685==  main thread stack using the --main-stacksize= flag.

==6685==  The main thread stack size used in this run was 8388608.

==6685== 

==6685== HEAP SUMMARY:

==6685==     in use at exit: 2,194,865 bytes in 9,747 blocks

==6685==   total heap usage: 522,330 allocs, 512,583 frees, 135,221,638 bytes allocated

==6685== 

==6685== LEAK SUMMARY:

==6685==    definitely lost: 14,607 bytes in 118 blocks

==6685==    indirectly lost: 4,224 bytes in 72 blocks

==6685==      possibly lost: 182,299 bytes in 3,628 blocks

==6685==    still reachable: 1,993,735 bytes in 5,929 blocks

==6685==         suppressed: 0 bytes in 0 blocks

==6685== Rerun with --leak-check=full to see details of leaked memory

==6685== 

==6685== For counts of detected and suppressed errors, rerun with: -v

==6685== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 2)

[Hajime Tazaki]

it seems there is memory corruption on your simulation, not
sure whether DCE or application on DCE has an issue.

what kind of simulation scenario are you conducting ?

-- Hajime

At Wed, 24 Jun 2015 10:02:37 -0700 (PDT),
mateus....@gmail.com wrote:
>
> [1 <multipart/alternative (7bit)>]
> [1.1 <text/plain; UTF-8 (7bit)>]

> --
> You received this message because you are subscribed to the Google Groups "ns-3-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to ns-3-users+...@googlegroups.com.
> To post to this group, send email to ns-3-...@googlegroups.com.
> Visit this group at http://groups.google.com/group/ns-3-users.
> For more options, visit https://groups.google.com/d/optout.
> [1.2 <text/html; UTF-8 (quoted-printable)>]
>

[mateus....@gmail.com]

Hello Hajime,

I am trying to execute the experiment described in http://yans.pl.sophia.inria.fr/trac/DCE/wiki/OVS_DCE. It is pretty much a SDN switch connecting to a SDN controller.

However, I replaced the NOX controller by the libfluid controller. The problem only happens when the controller is able to connect to the switch, so I guess it could be application. But I would like to discard the possibility that DCE has an issue, since libfluid seems to work fine outside DCE, and the problem happens around the DCE task manager.

If I use NOX instead of libfluid, DCE says that memcpy is not supported (relocation error), which is weird because it does not happen with other experiments.

Thanks  

Mateus

[Hajime Tazaki]

At Thu, 25 Jun 2015 07:24:40 -0700 (PDT),

mateus....@gmail.com wrote:
>
> Hello Hajime,
>
> I am trying to execute the experiment described
> in http://yans.pl.sophia.inria.fr/trac/DCE/wiki/OVS_DCE. It is pretty much
> a SDN switch connecting to a SDN controller.
> However, I replaced the NOX controller by the libfluid controller. The
> problem only happens when the controller is able to connect to the switch,
> so I guess it could be application. But I would like to discard the
> possibility that DCE has an issue, since libfluid seems to work fine
> outside DCE, and the problem happens around the DCE task manager.

could you try to increase the stack size for the application
(libfluid controller) ?

# DceApplicationHelper::SetStackSize () is the part.

> If I use NOX instead of libfluid, DCE says that memcpy is not supported
> (relocation error), which is weird because it does not happen with other
> experiments.

I also have no idea what's going on here.
is this something that you didn't add '-U_FORTIFY_SOURCE'
option to the CFLAGS ?

https://www.nsnam.org/docs/dce/manual/html/dce-user-newapps.html

-- Hajime

[mateus....@gmail.com]

Unfortunately, no progress at all. Tried a lot. :(

Perhaps I should try another linux distribution.

I appreciate the insights/ideas. 

Please do not hesitate to send any other comments if that's the case. I will keep working on that.

Thanks

mateus