Re: [nox-dev] Undefined symbol error running a NOX application. Compiling a NOX app with a linker flag.
To use hash_map and hash_set with some arbitrary type, you need to include a
hash function for that type (you only get some simple types like ints and
strings or something for free). The easiest way to do this is to specialize
hash with your type (you could also pass in a hash function explicitly when you
instantiate the hash_map/hash_set). This looks something like this:
namespace std {
namespace tr1 {
template< > struct hash< Link >
{
size_t operator() (const Link & key) const
{
return ;
}
};
}
}
It may be slightly different (the above should be correct for unordered_map /
unordered_set using GCC's c++0x stuff, but I don't remember if there are other
changes besides the name and the namespace), but that's the idea.
Hope that helps.
-- Murphy
On Sep 23, 2011, at 9:47 AM, Sergio Jiménez Feijóo wrote:
> Hi,
>
> Thank you for your help. Your method worked nicely and I no longer get errors
> because of the glkp library.
>
> Unluckily now I get another "undefined symbol" error message when I run the
> app (the code compiles without errors). I think this one might be caused
> because of the "hash" template which is defined in the hash.hh header file.
> It seems that is complaining about somewhat related to an operator.
>
> The message error I get is this:
>
> 00068|nox|ERR:Cannot change the state of 'elastictree' to INSTALLED:
> 'elastictree' ran into an error:
>Can't open a dynamic library: 'nox/netapps/elastictree/elastictree.so:
> cannot open shared object file: No such file or directory' or
> 'nox/netapps/elastictree/.libs/elastictree.so: undefined symbol:
> std::tr1::hash::operator()(vigil::Link) const'
>
> I can't determinate what exactly is causing this error but I can give you
> some hints:
>
> In my app I use several hash_map and hash_set objects and I have included
> both header files in my app's header file.
>
> I also created a struct named Link whose definition is as follows:
>
> struct Link {
>datapathid src_dpid, dst_dpid;
>uint16_t src_port, dst_port;
> };
>
> And the operators "==" and "!=" are defined as:
>
> bool operator==(const Link &a, const Link &b) {
>return ((a.src_dpid == b.src_dpid) && (a.dst_dpid == b.dst_dpid)
> && (a.src_port == b.src_port) && (a.dst_port == b.dst_port));
> }
>
> bool operator!=(const Link &a, const Link &b) {
>return !(a == b);
> }
>
> I would be very grateful you if you could give me some hints about what is
> likely to be causing this error.
>
> Thanks in advance.
>
> El 23/09/11 06:49, Murphy McCauley escribió:
>> In src/Makefile.am, around line 46 is something like:
>> nox_core_LDFLAGS = \
>>
>> Throw -lglpk in there too:
>> nox_core_LDFLAGS = -lglpk \
>>
>> Then re-run boot.sh in the top directory, and hopefully that'll do it.
>>
>> -- Murphy
>>
>> On Sep 22, 2011, at 8:33 AM, Sergio Jiménez Feijóo wrote:
>>
>>> Hi everybody,
>>>
>>> I've spent the last months developping a NOX application.
>>>
>>> The goal of my app is to dynamically calculate the optimum layer 2 path of
>>> OpenFlow switches for a flow between a source PC and a destination PC.
>>>
>>> The criteria which determines which path should be picked could be anything
>>> you want. In my case the criteria is to minimize the total power
>>> consumption of all the OpenFlow switches and links of the network.
>>>
>>> In order find a propper solution which accomplishes the selected criteria I
>>> need to use a Linear Programming solver. The GNU Linear Programming Kit
>>> (GLPK) library works like a charm for this purpose.
>>>
>>> I've included the glpk.h library in my header file and the NOX app compiles
>>> without errors but when I try to run the app I get an "undefined symbol"
>>> error when the code reaches the glpk library function calls. I think this
>>> might be caused because the gcc linker is running without the "-lglpk" flag.
>>>
>>> How could I modify the app's makefile to add this missing flag?
>>>
>>> Thanks for your help.
>>> ___
>>> nox-dev mailing list
>>> nox-dev@noxrepo.org
>>> http://noxrepo.org/mailman/listinfo/nox-dev
>
> ___
> nox-dev mailing list
> nox-dev@noxrepo.org
> http://noxrepo.org/mailman/listinfo/nox-dev
___
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev
Re: [nox-dev] Undefined symbol error running a NOX application. Compiling a NOX app with a linker flag.
Hi,
Thank you for your help. Your method worked nicely and I no longer get
errors because of the glkp library.
Unluckily now I get another "undefined symbol" error message when I run
the app (the code compiles without errors). I think this one might be
caused because of the "hash" template which is defined in the hash.hh
header file. It seems that is complaining about somewhat related to an
operator.
The message error I get is this:
00068|nox|ERR:Cannot change the state of 'elastictree' to INSTALLED:
'elastictree' ran into an error:
Can't open a dynamic library:
'nox/netapps/elastictree/elastictree.so: cannot open shared object file:
No such file or directory' or
'nox/netapps/elastictree/.libs/elastictree.so: undefined symbol:
std::tr1::hash::operator()(vigil::Link) const'
I can't determinate what exactly is causing this error but I can give
you some hints:
In my app I use several hash_map and hash_set objects and I have
included both header files in my app's header file.
I also created a struct named Link whose definition is as follows:
struct Link {
datapathid src_dpid, dst_dpid;
uint16_t src_port, dst_port;
};
And the operators "==" and "!=" are defined as:
bool operator==(const Link &a, const Link &b) {
return ((a.src_dpid == b.src_dpid) && (a.dst_dpid == b.dst_dpid)
&& (a.src_port == b.src_port) && (a.dst_port == b.dst_port));
}
bool operator!=(const Link &a, const Link &b) {
return !(a == b);
}
I would be very grateful you if you could give me some hints about what
is likely to be causing this error.
Thanks in advance.
El 23/09/11 06:49, Murphy McCauley escribió:
In src/Makefile.am, around line 46 is something like:
nox_core_LDFLAGS = \
Throw -lglpk in there too:
nox_core_LDFLAGS = -lglpk \
Then re-run boot.sh in the top directory, and hopefully that'll do it.
-- Murphy
On Sep 22, 2011, at 8:33 AM, Sergio Jiménez Feijóo wrote:
Hi everybody,
I've spent the last months developping a NOX application.
The goal of my app is to dynamically calculate the optimum layer 2 path of
OpenFlow switches for a flow between a source PC and a destination PC.
The criteria which determines which path should be picked could be anything you
want. In my case the criteria is to minimize the total power consumption of all
the OpenFlow switches and links of the network.
In order find a propper solution which accomplishes the selected criteria I
need to use a Linear Programming solver. The GNU Linear Programming Kit (GLPK)
library works like a charm for this purpose.
I've included the glpk.h library in my header file and the NOX app compiles without errors but when
I try to run the app I get an "undefined symbol" error when the code reaches the glpk
library function calls. I think this might be caused because the gcc linker is running without the
"-lglpk" flag.
How could I modify the app's makefile to add this missing flag?
Thanks for your help.
___
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev
___
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev
Re: [nox-dev] Getting dl_src, nw_src
Hi,
nw_src and nw_dst are 32-bit unsigned integers , i.e., binary values of the
IP address. This is how ofp_match is defined in OpenFlow. It might help to
read the spec for the exact definition.
Regards
KK
2011/9/23 Min-Hyup KANG
> Hi All,
>
>
> I would like to get dl_src, nw_src in void
> lavi_hostflow::send_flow_list(const Flow& flow, etc)
>
>
> So, I am printing some Flow values.
>
>
> For example, I used print function to get dl_src, nw_src.
>
>
> void lavi_hostflow::send_flow_list(const Flow& flow,
>
> const network::route& rte,
>
> const Msg_stream& stream,
>
> bool add)
>
> {
>
> ...
>
> ...
>
> std::cout<<"nw_src : "<
> std::cout<<"nw_dst : "<
> std::cout<<"dl_src : "<
> std::cout<<"dl_dst : "<
> }
>
>
> and Below is outcome.
>
> As you can see, dl_src looks good, but nw_src isn't IP address..
>
> To get IP src,dst Address, What should I do ?
>
>
> ./nox_core
>
> .
>
> .
> nw_src : 16885952
> nw_dst : 33663168
> dl_src : 00:0f:b0:72:1b:e3
> dl_dst : 00:0f:b0:6f:ea:e2
> .
> .
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Best Regards,
> Min-Hyup KANG
>
>
> ___
> nox-dev mailing list
> nox-dev@noxrepo.org
> http://noxrepo.org/mailman/listinfo/nox-dev
>
>
___
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev
[nox-dev] Getting dl_src, nw_src
Hi All,I would like to get dl_src, nw_src in void lavi_hostflow::send_flow_list(const Flow& flow, etc)So, I am printing some Flow values.For example, I used print function to get dl_src, nw_src.void lavi_hostflow::send_flow_list(const Flow& flow, const network::route& rte, const Msg_stream& stream, bool add) {..std::cout<<"nw_src : "
Re: [nox-dev] Debugging call for help: Assertion '_M_ptr != 0'
Hi Murphy, thank you _very_ much for your hints and the explanation behind tx_buf! We are looking on using the messenger component directly (Thanks KK!). Some time ago we did try implementing the cooperative threading as the first approach what we missed for some reason we do no recall. We will report back as soon as we get a working solution. Cheers, Christian On Fri, Sep 23, 2011 at 08:47, Murphy McCauley wrote: > For clarification of my earlier post: > > The race condition concerns tx_buf in lib/openflow.cc. If > Openflow_connection::send_packet() is called by one thread at a time, tx_buf > is always checked (via tx_buf.get()) to see if it's empty before it's sent, > after which it's cleared (tx_buf.reset()). But when you have another thread > calling it at the same time, this doesn't hold true anymore. After a > tx_buf.get() check in Thread A, Thread B is getting in, checking > tx_buf.get(), and then doing a tx_buf.reset(). When Thread A then tries to > use tx_buf, it has now been reset() without Thread A's knowledge. > > > And an amendment: > > I said earlier that the solution I'd suggest was rewriting your server thread > as a cooperative thread. That'd now be my second choice. KK's suggestion is > better -- if possible, rewrite your communication to use the messenger > component instead. > > > -- Murphy > > On Sep 23, 2011, at 2:55 AM, kk yap wrote: > >> Hi Christian, >> >> I need to take a deeper look to give any constructive comment but your >> use of auto_ptr should be at fault. This can be a memory allocation >> problem. As Murphy hinted on, you might want to use the facilities >> available in NOX to help rather than write everything on your own. >> For example, messenger does binary messages on a TCP connection >> already, and it uses cooperative thread---so that should help. >> >> Regards >> KK >> >> On 22 September 2011 22:48, Murphy McCauley wrote: >>> I think this is a race condition because you're calling >>> send_openflow_packet() from a non-cooperative thread. >>> I think your best bet is probably to rewrite your server thread as a >>> cooperative thread. >>> There are other options... you could have queue which is consumed by a >>> simple cooperative thread and does the actual sends from there. Or... I >>> can't remember for sure if the cooperative threading library supports >>> scheduling one thread group from a native thread, but... when you want to >>> send from the native thread, schedule a cooperative thread (and then wait >>> for it to run) which just blocks until you're done sending from the native >>> thread. Or you could put locks into NOX's async output stuff (I would >>> suggest not doing that). There are probably lots of other options too. I'd >>> still suggest rewriting your server thread as a cooperative thread if >>> possible. :) >>> Hope that helps. >>> -- Murphy >>> On Sep 21, 2011, at 11:06 AM, Christian Esteve Rothenberg wrote: >>> >>> Dear NOX friends, >>> >>> we are facing a nasty bug and we would very much appreciate any help >>> in debugging and understanding the root cause. We have been >>> struggling for some time now... :( >>> >>> The code base is fairly simple and has worked well for some time, >>> but for some reason it has started to crash: >>> https://github.com/chesteve/RouteFlow/blob/master/rf-controller/src/nox/netapps/routeflowc/routeflowc.cc >>> >>> As fas as I can tell, the code has remained unchanged and only the datapath >>> and application traffic (i.e., payload of packet-in and packet-out packets) >>> has changed. >>> >>> >>> This is the error we are seeing in NOX, a failed assertion: >>> >>> /usr/include/c++/4.5/backward/auto_ptr.h:194: element_type* >>> std::auto_ptr<_Tp>::operator->() const [with _Tp = vigil::Buffer, >>> element_type = vigil::Buffer]: Assertion '_M_ptr != 0' failed. >>> Caught signal 6. >>> 0xb74ae2be 64 (vigil::fault_handler(int)+0x4e) >>> 0xb7748400 3068602152 (__kernel_sigreturn+0x0) >>> 0xb71dc34e 296 (abort+0x17e) >>> 0xb74ecc11 80 (vigil::Openflow_stream_connection::send_tx_buf()+0x121) >>> 0xb74ece21 80 >>> (vigil::Openflow_stream_connection::do_send_openflow(ofp_header >>> const*)+0xc1) >>> 0xb74ed7cf 80 >>> (vigil::Openflow_connection::call_send_openflow(ofp_header >>> const*)+0x2f) >>> 0xb74ee14f 64 >>> (vigil::Openflow_connection::send_openflow(ofp_header const*, >>> bool)+0x5f) >>> 0xb74eedae 96 >>> (vigil::Openflow_connection::send_packet(vigil::Buffer const&, >>> ofp_action_header const*, unsigned int, unsigned short, bool)+0xfe) >>> 0xb74eeeb9 96 >>> (vigil::Openflow_connection::send_packet(vigil::Buffer const&, >>> unsigned short, unsigned short, bool)+0x79) >>> 0xb75f18b4 96 >>> (vigil::nox::send_openflow_packet_out(vigil::datapathid const&, >>> vigil::Buffer const&, unsigned short, unsigned short, bool)+0x74) >>> 0xb75ce7cc 48 >>> (vigil::container::Component::send_openflow_packet(vigil::datapathid >>> const&, vigil::Buffer const&, unsigned
Re: [nox-dev] Debugging call for help: Assertion '_M_ptr != 0'
For clarification of my earlier post: The race condition concerns tx_buf in lib/openflow.cc. If Openflow_connection::send_packet() is called by one thread at a time, tx_buf is always checked (via tx_buf.get()) to see if it's empty before it's sent, after which it's cleared (tx_buf.reset()). But when you have another thread calling it at the same time, this doesn't hold true anymore. After a tx_buf.get() check in Thread A, Thread B is getting in, checking tx_buf.get(), and then doing a tx_buf.reset(). When Thread A then tries to use tx_buf, it has now been reset() without Thread A's knowledge. And an amendment: I said earlier that the solution I'd suggest was rewriting your server thread as a cooperative thread. That'd now be my second choice. KK's suggestion is better -- if possible, rewrite your communication to use the messenger component instead. -- Murphy On Sep 23, 2011, at 2:55 AM, kk yap wrote: > Hi Christian, > > I need to take a deeper look to give any constructive comment but your > use of auto_ptr should be at fault. This can be a memory allocation > problem. As Murphy hinted on, you might want to use the facilities > available in NOX to help rather than write everything on your own. > For example, messenger does binary messages on a TCP connection > already, and it uses cooperative thread---so that should help. > > Regards > KK > > On 22 September 2011 22:48, Murphy McCauley wrote: >> I think this is a race condition because you're calling >> send_openflow_packet() from a non-cooperative thread. >> I think your best bet is probably to rewrite your server thread as a >> cooperative thread. >> There are other options... you could have queue which is consumed by a >> simple cooperative thread and does the actual sends from there. Or... I >> can't remember for sure if the cooperative threading library supports >> scheduling one thread group from a native thread, but... when you want to >> send from the native thread, schedule a cooperative thread (and then wait >> for it to run) which just blocks until you're done sending from the native >> thread. Or you could put locks into NOX's async output stuff (I would >> suggest not doing that). There are probably lots of other options too. I'd >> still suggest rewriting your server thread as a cooperative thread if >> possible. :) >> Hope that helps. >> -- Murphy >> On Sep 21, 2011, at 11:06 AM, Christian Esteve Rothenberg wrote: >> >> Dear NOX friends, >> >> we are facing a nasty bug and we would very much appreciate any help >> in debugging and understanding the root cause. We have been >> struggling for some time now... :( >> >> The code base is fairly simple and has worked well for some time, >> but for some reason it has started to crash: >> https://github.com/chesteve/RouteFlow/blob/master/rf-controller/src/nox/netapps/routeflowc/routeflowc.cc >> >> As fas as I can tell, the code has remained unchanged and only the datapath >> and application traffic (i.e., payload of packet-in and packet-out packets) >> has changed. >> >> >> This is the error we are seeing in NOX, a failed assertion: >> >> /usr/include/c++/4.5/backward/auto_ptr.h:194: element_type* >> std::auto_ptr<_Tp>::operator->() const [with _Tp = vigil::Buffer, >> element_type = vigil::Buffer]: Assertion '_M_ptr != 0' failed. >> Caught signal 6. >> 0xb74ae2be 64 (vigil::fault_handler(int)+0x4e) >> 0xb7748400 3068602152 (__kernel_sigreturn+0x0) >> 0xb71dc34e 296 (abort+0x17e) >> 0xb74ecc11 80 (vigil::Openflow_stream_connection::send_tx_buf()+0x121) >> 0xb74ece21 80 >> (vigil::Openflow_stream_connection::do_send_openflow(ofp_header >> const*)+0xc1) >> 0xb74ed7cf 80 >> (vigil::Openflow_connection::call_send_openflow(ofp_header >> const*)+0x2f) >> 0xb74ee14f 64 >> (vigil::Openflow_connection::send_openflow(ofp_header const*, >> bool)+0x5f) >> 0xb74eedae 96 >> (vigil::Openflow_connection::send_packet(vigil::Buffer const&, >> ofp_action_header const*, unsigned int, unsigned short, bool)+0xfe) >> 0xb74eeeb9 96 >> (vigil::Openflow_connection::send_packet(vigil::Buffer const&, >> unsigned short, unsigned short, bool)+0x79) >> 0xb75f18b4 96 >> (vigil::nox::send_openflow_packet_out(vigil::datapathid const&, >> vigil::Buffer const&, unsigned short, unsigned short, bool)+0x74) >> 0xb75ce7cc 48 >> (vigil::container::Component::send_openflow_packet(vigil::datapathid >> const&, vigil::Buffer const&, unsigned short, unsigned short, bool) >> const+0x3c) >> >> >> Using gdb, the backtrace is as follows: >> >> >> (gdb) bt >> #0 0xb772c367 in ?? () from /lib/ld-linux.so.2 >> #1 0xb772c979 in ?? () from /lib/ld-linux.so.2 >> #2 0xb7730a31 in ?? () from /lib/ld-linux.so.2 >> #3 0xb7736c40 in ?? () from /lib/ld-linux.so.2 >> #4 0xb7487dc2 in fgets () at /usr/include/bits/stdio2.h:255 >> #5 read_mem_map () at ../../../src/lib/fault.cc:79 >> #6 vigil::dump_backtrace () at ../../../src/lib/fault.cc:180 >> #7 0xb74882be in vigil:
Re: [nox-dev] Debugging call for help: Assertion '_M_ptr != 0'
Hi Christian, I need to take a deeper look to give any constructive comment but your use of auto_ptr should be at fault. This can be a memory allocation problem. As Murphy hinted on, you might want to use the facilities available in NOX to help rather than write everything on your own. For example, messenger does binary messages on a TCP connection already, and it uses cooperative thread---so that should help. Regards KK On 22 September 2011 22:48, Murphy McCauley wrote: > I think this is a race condition because you're calling > send_openflow_packet() from a non-cooperative thread. > I think your best bet is probably to rewrite your server thread as a > cooperative thread. > There are other options... you could have queue which is consumed by a > simple cooperative thread and does the actual sends from there. Or... I > can't remember for sure if the cooperative threading library supports > scheduling one thread group from a native thread, but... when you want to > send from the native thread, schedule a cooperative thread (and then wait > for it to run) which just blocks until you're done sending from the native > thread. Or you could put locks into NOX's async output stuff (I would > suggest not doing that). There are probably lots of other options too. I'd > still suggest rewriting your server thread as a cooperative thread if > possible. :) > Hope that helps. > -- Murphy > On Sep 21, 2011, at 11:06 AM, Christian Esteve Rothenberg wrote: > > Dear NOX friends, > > we are facing a nasty bug and we would very much appreciate any help > in debugging and understanding the root cause. We have been > struggling for some time now... :( > > The code base is fairly simple and has worked well for some time, > but for some reason it has started to crash: > https://github.com/chesteve/RouteFlow/blob/master/rf-controller/src/nox/netapps/routeflowc/routeflowc.cc > > As fas as I can tell, the code has remained unchanged and only the datapath > and application traffic (i.e., payload of packet-in and packet-out packets) > has changed. > > > This is the error we are seeing in NOX, a failed assertion: > > /usr/include/c++/4.5/backward/auto_ptr.h:194: element_type* > std::auto_ptr<_Tp>::operator->() const [with _Tp = vigil::Buffer, > element_type = vigil::Buffer]: Assertion '_M_ptr != 0' failed. > Caught signal 6. > 0xb74ae2be 64 (vigil::fault_handler(int)+0x4e) > 0xb7748400 3068602152 (__kernel_sigreturn+0x0) > 0xb71dc34e 296 (abort+0x17e) > 0xb74ecc11 80 (vigil::Openflow_stream_connection::send_tx_buf()+0x121) > 0xb74ece21 80 > (vigil::Openflow_stream_connection::do_send_openflow(ofp_header > const*)+0xc1) > 0xb74ed7cf 80 > (vigil::Openflow_connection::call_send_openflow(ofp_header > const*)+0x2f) > 0xb74ee14f 64 > (vigil::Openflow_connection::send_openflow(ofp_header const*, > bool)+0x5f) > 0xb74eedae 96 > (vigil::Openflow_connection::send_packet(vigil::Buffer const&, > ofp_action_header const*, unsigned int, unsigned short, bool)+0xfe) > 0xb74eeeb9 96 > (vigil::Openflow_connection::send_packet(vigil::Buffer const&, > unsigned short, unsigned short, bool)+0x79) > 0xb75f18b4 96 > (vigil::nox::send_openflow_packet_out(vigil::datapathid const&, > vigil::Buffer const&, unsigned short, unsigned short, bool)+0x74) > 0xb75ce7cc 48 > (vigil::container::Component::send_openflow_packet(vigil::datapathid > const&, vigil::Buffer const&, unsigned short, unsigned short, bool) > const+0x3c) > > > Using gdb, the backtrace is as follows: > > > (gdb) bt > #0 0xb772c367 in ?? () from /lib/ld-linux.so.2 > #1 0xb772c979 in ?? () from /lib/ld-linux.so.2 > #2 0xb7730a31 in ?? () from /lib/ld-linux.so.2 > #3 0xb7736c40 in ?? () from /lib/ld-linux.so.2 > #4 0xb7487dc2 in fgets () at /usr/include/bits/stdio2.h:255 > #5 read_mem_map () at ../../../src/lib/fault.cc:79 > #6 vigil::dump_backtrace () at ../../../src/lib/fault.cc:180 > #7 0xb74882be in vigil::fault_handler (sig_nr=6) at > ../../../src/lib/fault.cc:280 > #8 > #9 0xb7722424 in __kernel_vsyscall () > #10 0xb71b2e71 in raise (sig=6) at > ../nptl/sysdeps/unix/sysv/linux/raise.c:64 > #11 0xb71b634e in abort () at abort.c:92 > #12 0xb74c6c11 in __replacement_assert (this=0x93d7830) at > /usr/include/c++/4.5/i686-linux-gnu/bits/c++config.h:326 > #13 operator-> (this=0x93d7830) at > /usr/include/c++/4.5/backward/auto_ptr.h:194 > #14 vigil::Openflow_stream_connection::send_tx_buf (this=0x93d7830) at > ../../../src/lib/openflow.cc:824 > #15 0xb74c6e21 in vigil::Openflow_stream_connection::do_send_openflow > (this=0x93d7830, oh=0x9104c50) at ../../../src/lib/openflow.cc:844 > #16 0xb74c77cf in vigil::Openflow_connection::call_send_openflow > (this=0x93d7830, oh=0x9104c50) at ../../../src/lib/openflow.cc:248 > #17 0xb74c814f in vigil::Openflow_connection::send_openflow > (this=0x93d7830, oh=0x9104c50, block=true) at > ../../../src/lib/openflow.cc:232 > #18 0xb74c8dae in vigil::Openflow_connection::send_packet > (this=0x93d7830, packet=.
