青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品

focus on linux, c/c++, lua

被delete難倒了

話說(shuō)我有一個(gè)結(jié)構(gòu)體如下:
struct stReplayData
{
    
int nDelay;        // 該數(shù)據(jù)在上一條消息之后的延遲,仿真(目前自定義1秒鐘)
    char* pData;    // 網(wǎng)絡(luò)數(shù)據(jù)包的內(nèi)容
    int nLen;        // 長(zhǎng)度

    stReplayData()
    
{
        nDelay 
= 0;
        nLen 
= 0;
        pData 
= NULL;
    }


    stReplayData(
int nLength)
    
{
        nDelay 
= 0;
        nLen 
= nLength;
        pData 
= NULL;
        
if (nLen > 0)
        
{
            pData 
= new char[nLen];
        }
                
    }


    stReplayData(
const stReplayData& src)
    
{
        
if (this == &src)
        
{
            
return;
        }

        
*this = src;
    }


    stReplayData
& operator = (const stReplayData& src)
    
{
        
if (this == &src)
        
{
            
return *this;
        }

        nDelay 
= src.nDelay;
        
if (pData != NULL)
        
{
            delete[] pData;
            pData 
= NULL;
        }
        
        nLen 
= src.nLen;
        
if (nLen > 0)
        
{
            pData 
= new char[nLen];        
            memcpy(pData, src.pData, nLen);
        }

        
return *this;
    }


    
~stReplayData()
    
{
        nDelay 
= 0;
        nLen 
= 0;
        
if (pData != NULL)
        
{
            delete[] pData;            
            pData 
= NULL;
        }
        
    }

}
;

我定義了一個(gè)vector<stReplayData*> m_vecReplay,然后new了一些stReplayData ,push_back這些指針進(jìn)去,最后程序釋放資源的時(shí)候,居然報(bào)調(diào)用釋放指針出錯(cuò)了,報(bào)的錯(cuò)就是平時(shí)見(jiàn)的很多的Heap上指針無(wú)效的錯(cuò)誤,基本上是說(shuō)stReplayData的析構(gòu)函數(shù)有問(wèn)題,我了個(gè)擦,我怎么沒(méi)看出哪里有問(wèn)題呢?

=====================================更多的代碼如下===============================================
我封裝了一個(gè)dll作為一個(gè)公共模塊,自然數(shù)據(jù)都會(huì)在這個(gè)公共模塊中存儲(chǔ),其中內(nèi)存數(shù)據(jù)的管理也會(huì)在這個(gè)dll中去做,也就是說(shuō),new和delete都會(huì)由這個(gè)dll自己去管理,
使用者只要去調(diào)接口,然后把需要存儲(chǔ)的數(shù)據(jù)地址傳給dll,讓dll自己去拷貝即可。模塊其實(shí)非常簡(jiǎn)單:
class CReplayManager : public IReplayManager
{
    typedef vector
<stReplayData*> VECREPLAY;
public:
    CReplayManager();
    
virtual ~CReplayManager();
    
virtual bool PushData(stReplayData* pData);
    
virtual stReplayData* PopData();
    
virtual stReplayData* GetTailData();
    
virtual void ClearData();
    
virtual void Release();    
private:
    VECREPLAY m_vecReplay;
}
;
這里還有個(gè)模版函數(shù),讓主程序朝dll寫數(shù)據(jù),
template<class M, class T>
void WriteReplay(M* m, const T& t)
{
    CWrite cw;
    cw.Write(t);
    stReplayData
* pReplay = new stReplayData(cw.GetLen());
    
if (pReplay != NULL)
    
{        
        pReplay
->nLen = cw.GetLen();
        memcpy(pReplay
->pData, cw.GetData(), cw.GetLen());
        m
->PushData(pReplay);
    }
        
}
另:在主程序里單獨(dú)的操作stReplayData是沒(méi)什么問(wèn)題的,我也試驗(yàn)過(guò)。

=================================總結(jié)=================================
re: 被delete難倒了 2011-03-31 11:49 dizhu

問(wèn)題就是SAFE_DELETE((*it)); 這個(gè)是在exe中new的,不能在dll中delete。

深入:
如果一個(gè)EXE調(diào)用一個(gè)DLL時(shí),用new和delete分配和釋放內(nèi)存為什么應(yīng)該放在同一個(gè)背景下的原因。得出的結(jié)論是,如果EXE和DLL有一個(gè)不是用動(dòng)態(tài)鏈接CRT庫(kù)(C   runtime   library)的方式使用CRT的話(Multi-threaded Debug DLL (/MDd)),或者是EXE和DLL動(dòng)態(tài)鏈接的CRT庫(kù)的版本不同時(shí),EXE和DLL將會(huì)各自擁有各自的堆空間,所以在DLL中new的東西務(wù)必在DLL中delete。

posted on 2011-03-30 17:29 zuhd 閱讀(2222) 評(píng)論(29)  編輯 收藏 引用 所屬分類: c/c++

評(píng)論

# re: 被delete難倒了 2011-03-30 17:36 namelij

你去看看vector里面的對(duì)象是怎么釋放的,就明白了  回復(fù)  更多評(píng)論   

# re: 被delete難倒了 2011-03-30 17:46 dizhu

貼下完整的代碼  回復(fù)  更多評(píng)論   

# re: 被delete難倒了 2011-03-30 17:50 Kevin Lynx

@dizhu
問(wèn)題確實(shí)可能出在其他地方。  回復(fù)  更多評(píng)論   

# re: 被delete難倒了 2011-03-30 17:55 千暮(zblc)

我按你說(shuō)的做了一遍 沒(méi)有報(bào)錯(cuò) - -bnr 你咋不把調(diào)用的代碼發(fā)下  回復(fù)  更多評(píng)論   

# re: 被delete難倒了[未登錄](méi) 2011-03-30 20:58 vincent

應(yīng)該還是也指著啊  回復(fù)  更多評(píng)論   

# re: 被delete難倒了[未登錄](méi) 2011-03-30 20:59 vincent

野指針……  回復(fù)  更多評(píng)論   

# re: 被delete難倒了 2011-03-31 00:50 Mensch88

1. 就這段代碼本身來(lái)說(shuō),有一個(gè)錯(cuò)誤:拷貝構(gòu)造函數(shù) stReplayData(const stReplayData& src) 里的指針pData沒(méi)有初始化!

2.stReplayData的析構(gòu)函數(shù)本身沒(méi)有問(wèn)題。程序報(bào)錯(cuò)應(yīng)該是調(diào)用了兩次析構(gòu)函數(shù)造成的。
比如說(shuō),很有可能在使用時(shí)會(huì)犯這樣的錯(cuò)誤:
stReplayData data(otherdata);
vec.push_back(&data);
由于data本身會(huì)調(diào)用析構(gòu)函數(shù)delete pData,而delete vec里面的數(shù)據(jù)時(shí)也會(huì)調(diào)用data的析構(gòu)函數(shù),于是掛了。

  回復(fù)  更多評(píng)論   

# re: 被delete難倒了 2011-03-31 01:13 Mensch88

不好意思,第二點(diǎn)我說(shuō)得不大對(duì),因?yàn)闃侵髟谖鰳?gòu)函數(shù)里判斷了 if (pData != NULL), 并且之后會(huì)把pData=NULL,所以調(diào)用兩次析構(gòu)在單線程環(huán)境里不會(huì)問(wèn)題。當(dāng)然多線程環(huán)境下就另說(shuō)了。

但我所陳述的問(wèn)題依然是存在的,只是這不是因?yàn)閮纱挝鰳?gòu)造成,而是因?yàn)閐ata是棧上的數(shù)據(jù),不允許delete,所以掛了。  回復(fù)  更多評(píng)論   

# re: 被delete難倒了 2011-03-31 09:14 zuhd

@Mensch88
1. 就這段代碼本身來(lái)說(shuō),有一個(gè)錯(cuò)誤:拷貝構(gòu)造函數(shù) stReplayData(const stReplayData& src) 里的指針pData沒(méi)有初始化!

拷貝構(gòu)造函數(shù)是調(diào)用operator =來(lái)著  回復(fù)  更多評(píng)論   

# re: 被delete難倒了 2011-03-31 09:36 dizhu

@Mensch88
vector里面保存的是指針,不會(huì)調(diào)用delete 的,不會(huì)存在你說(shuō)的兩次析構(gòu)函數(shù)調(diào)用  回復(fù)  更多評(píng)論   

# re: 被delete難倒了 2011-03-31 09:39 dizhu

@dizhu
如果樓主
stReplayData data(otherdata);
vec.push_back(&data);
然后還去delete vec里面的數(shù)據(jù),那就是樓主代碼寫的有問(wèn)題,所以說(shuō)還是貼下完整的代碼,才能知道問(wèn)題。但就這個(gè)stReplayData,還真看不出為什么會(huì)掛  回復(fù)  更多評(píng)論   

# re: 被delete難倒了 2011-03-31 10:13 zuhd

我更新了帖子 貼了更多的代碼 想嘗試的朋友 可以自己簡(jiǎn)單修改下即可  回復(fù)  更多評(píng)論   

# re: 被delete難倒了 2011-03-31 11:13 zuhd

問(wèn)題我找到了,是我以前遇到的老問(wèn)題
virtual bool PushData(stReplayData* pData);
這個(gè)接口設(shè)計(jì)有問(wèn)題,dll的接口應(yīng)該用標(biāo)準(zhǔn)的c++類型,我只知道其然,不知道所以然,了解詳情的說(shuō)下  回復(fù)  更多評(píng)論   

# re: 被delete難倒了 2011-03-31 11:17 dizhu

@zuhd
重點(diǎn)把delete stReplayData 的代碼 和 CReplayManager 貼出來(lái)看下  回復(fù)  更多評(píng)論   

# re: 被delete難倒了 2011-03-31 11:22 zuhd

@dizhu
看了頭文件基本就能猜到代碼了吧 中規(guī)中矩的容器操作代碼而已

另:我在gcc中的頭文件大量的使用了自定義的類,貌似沒(méi)發(fā)現(xiàn)過(guò)什么問(wèn)題,怎么用vc上來(lái)就碰到這個(gè),是巧合還是必然?腫么辦?有沒(méi)有,有沒(méi)有?  回復(fù)  更多評(píng)論   

# re: 被delete難倒了 2011-03-31 11:24 dizhu

@zuhd
我比較關(guān)心CReplayManager 的Release 以及 ClearData 的實(shí)現(xiàn)。是不是在這里面delete stReplayData 了??  回復(fù)  更多評(píng)論   

# re: 被delete難倒了 2011-03-31 11:41 zuhd

void CReplayManager::ClearData()
{
VECREPLAY::iterator it = m_vecReplay.begin();
for (; it != m_vecReplay.end(); it++)
{
SAFE_DELETE((*it));
}
m_vecReplay.clear();
}  回復(fù)  更多評(píng)論   

# re: 被delete難倒了 2011-03-31 11:49 dizhu

@zuhd
void CReplayManager::ClearData()
{
VECREPLAY::iterator it = m_vecReplay.begin();
for (; it != m_vecReplay.end(); it++)
{
SAFE_DELETE((*it));
}
m_vecReplay.clear();
}
問(wèn)題就是SAFE_DELETE((*it)); 這個(gè)是在exe中new的,不能在dll中delete。
原因:http://blog.csdn.net/blz_wowar/archive/2008/03/13/2176536.aspx  回復(fù)  更多評(píng)論   

# re: 被delete難倒了 2011-03-31 11:56 zuhd

@dizhu
在exe中new,不能在dll中delete的?
exe和dll用的是同一個(gè)堆棧空間的,  回復(fù)  更多評(píng)論   

# re: 被delete難倒了 2011-03-31 17:48 Mensch88

zuhd@zuhd
--拷貝構(gòu)造函數(shù)是調(diào)用operator =來(lái)著

拷貝構(gòu)造函數(shù)是調(diào)用了operator=,但是operator=里面會(huì)判斷pData是否為NULL:
if (pData != NULL)
{
delete[] pData;
pData = NULL;
}
必須注意的是,這時(shí)pData還沒(méi)有被初始化。這樣就會(huì)執(zhí)行 delete[] pData;
從而出錯(cuò)。  回復(fù)  更多評(píng)論   

# re: 被delete難倒了 2011-03-31 17:55 Mensch88

@dizhu
--然后還去delete vec里面的數(shù)據(jù),那就是樓主代碼寫的有問(wèn)題,所以說(shuō)還是貼下完整的代碼,才能知道問(wèn)題。但就這個(gè)stReplayData,還真看不出為什么會(huì)掛

因?yàn)闃侵髡f(shuō)了vec里面是一些new出來(lái)的指針,而之后程序釋放資源時(shí)報(bào)錯(cuò),于是我估計(jì)樓主所說(shuō)的程序釋放資源就是指將vec里面的指針delete。
樓主后來(lái)的代碼也證實(shí)了我的猜測(cè)。

  回復(fù)  更多評(píng)論   

# re: 被delete難倒了 2011-03-31 18:31 Mensch88

樓主的問(wèn)題算是CRT的bug么?
Linux下測(cè)試,無(wú)論是靜態(tài)還是動(dòng)態(tài)鏈接都沒(méi)發(fā)現(xiàn)這種問(wèn)題。  回復(fù)  更多評(píng)論   

# re: 被delete難倒了 2011-03-31 23:54 flyinghearts


建議還是用 vector<char> 或 string 代替 char*

stReplayData 設(shè)計(jì)得有點(diǎn)問(wèn)題,
一般都是 在拷貝構(gòu)造函數(shù)中進(jìn)行分配新內(nèi)存處理, 然后在賦值函數(shù)中調(diào)用拷貝構(gòu)造函數(shù),構(gòu)造一個(gè)臨時(shí)類對(duì)像,與原類對(duì)象進(jìn)行交換。

你的實(shí)現(xiàn)剛好相反,拷貝構(gòu)造函數(shù)調(diào)用 賦值函數(shù),但 賦值函數(shù)中用到的 nlen 和 pdata兩個(gè)值都未初始化,UB行為。

實(shí)際上,這兩個(gè)判斷都是可以去掉的,new char[0] 是有意義的,沒(méi)必要對(duì) nlen進(jìn)行判斷
delete[] p 當(dāng)p是空指針時(shí),沒(méi)有任何效果,因此沒(méi)必要對(duì)pdata進(jìn)行判斷

拷貝構(gòu)造函數(shù)中 對(duì)指針的判斷 也是多余的。
另外,要先分配新內(nèi)存,再釋放舊內(nèi)存,保證 異常安全。

  回復(fù)  更多評(píng)論   

# re: 被delete難倒了 2011-04-01 09:44 zuhd

@flyinghearts
那個(gè)拷貝構(gòu)造函數(shù)確實(shí)有點(diǎn)問(wèn)題,以前拷貝構(gòu)造函數(shù)調(diào)用=寫順手了,沒(méi)發(fā)現(xiàn)有內(nèi)存操作的這么寫有這個(gè)陷阱,改了一下:
stReplayData(const stReplayData& src)
{
if (this == &src)
{
return;
}
nDelay = src.nDelay;
nLen = src.nLen;
pData = new char[nLen];
if (pData != NULL)
{
memcpy(pData, src.pData, nLen);
}
}

stReplayData& operator = (const stReplayData& src)
{
if (this == &src)
{
return *this;
}
nDelay = src.nDelay;
nLen = src.nLen;
if (pData != NULL)
{
delete[] pData;
pData = NULL;
}
pData = new char[nLen];
if (pData != NULL)
{
memcpy(pData, src.pData, nLen);
}
return *this;
}

至于你說(shuō)的:
另外,要先分配新內(nèi)存,再釋放舊內(nèi)存,保證 異常安全。
好像我一直都是先delete 再new ,可能一直懶得用個(gè)臨時(shí)的指針來(lái)保存pData吧,不過(guò)你這么說(shuō)的道理是??  回復(fù)  更多評(píng)論   

# re: 被delete難倒了[未登錄](méi) 2011-04-01 11:32 hdqqq

如果樓主使用 /mt 編譯,dll啟動(dòng)時(shí)使用自己的堆, 在主程序中new 出來(lái)的對(duì)象,再通過(guò)指針傳給dll,然后在dll中釋放,會(huì)產(chǎn)生錯(cuò)誤,主程序和dll使用不同的堆。  回復(fù)  更多評(píng)論   

# re: 被delete難倒了[未登錄](méi) 2011-04-01 14:39 楊粼波

把struct改為class,然后把數(shù)據(jù)private,測(cè)試一次看看。排除客戶代碼應(yīng)用上的錯(cuò)誤。

當(dāng)然了,也有可能在調(diào)用的時(shí)候,被其他地方的錯(cuò)誤牽連導(dǎo)致這個(gè)struct的數(shù)據(jù)被損壞。

如果牽扯到DLL的話,那有可能是exe和dll兩者之間的版本不一致所導(dǎo)致,DLL的導(dǎo)出地址是用的一個(gè),卻不想exe用了另外一個(gè),所以發(fā)生錯(cuò)誤,這是有可能發(fā)生的。用VS的編譯器,特別是2003,你需要依照以下步驟重編譯:清理全部(包括dll和exe)->重編。  回復(fù)  更多評(píng)論   

# re: 被delete難倒了[未登錄](méi) 2011-04-01 15:40 楊粼波

http://blog.csdn.net/ssli/archive/2009/06/16/4272484.aspx  回復(fù)  更多評(píng)論   

# re: 被delete難倒了 2011-04-01 23:30 flyinghearts

 
class stReplayData
{
  
int nDelay;     // 該數(shù)據(jù)在上一條消息之后的延遲,仿真(目前自定義1秒鐘)
  size_t nLen;  // 長(zhǎng)度
  char* pData;    // 網(wǎng)絡(luò)數(shù)據(jù)包的內(nèi)容
  
public:  
  stReplayData(size_t nLength 
= 0): nDelay(0), 
      nLen(nLength), pData(
new char[nLength]()) {}
  
  
~stReplayData() { delete[] pData; }
  
  stReplayData(
const stReplayData& src):  nDelay(src.nDelay),
      nLen(src.nLen), pData(
new char[src.nLen]) 
  {
    memcpy(pData, src.pData, nLen);  
  }
    
  stReplayData
& operator=(stReplayData tmp) //構(gòu)建一個(gè)臨時(shí)對(duì)像
  {
    nDelay 
= tmp.nDelay;
    nLen 
= tmp.nLen;
    std::swap(pData, tmp.pData);
    
return *this;
  }
};

 
可參考以前寫的這篇文章:
http://blog.csdn.net/flyinghearts/archive/2010/06/16/5673089.aspx
  回復(fù)  更多評(píng)論   

# re: 被delete難倒了 2011-04-02 11:42 tingya

涉及到跨模塊內(nèi)存使用的問(wèn)題,應(yīng)該遵守誰(shuí)使用,誰(shuí)釋放  回復(fù)  更多評(píng)論   

青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品
  • <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            亚洲国产高清一区二区三区| 午夜精品免费| 国产老女人精品毛片久久| 亚洲六月丁香色婷婷综合久久| 亚洲大胆美女视频| 久久久久五月天| 狠狠色狠狠色综合| 老司机午夜精品视频在线观看| 久久资源在线| 一本色道久久综合亚洲精品不| 欧美日韩美女一区二区| 亚洲一区二区3| 毛片一区二区| 午夜精品久久| 在线成人免费观看| 国产精品国产三级国产普通话三级| 亚洲欧美日韩中文在线制服| 亚洲国产欧美在线人成| 99精品久久| 亚洲国产精品一区制服丝袜| 亚洲欧美欧美一区二区三区| 亚洲动漫精品| 一区精品久久| 国产精品一区二区在线观看不卡| 欧美成年视频| 欧美成ee人免费视频| 欧美中日韩免费视频| 999在线观看精品免费不卡网站| 另类av导航| 欧美aa国产视频| 久久中文久久字幕| 久久欧美中文字幕| 女主播福利一区| 美女999久久久精品视频| 久久人人97超碰国产公开结果 | 夜夜爽夜夜爽精品视频| 国内成人在线| 国内成人精品视频| 国产在线精品自拍| 好吊妞**欧美| 亚洲黄色一区二区三区| 亚洲精品孕妇| 日韩天天综合| 久久不射2019中文字幕| 在线观看一区欧美| 99国产精品私拍| 国外成人在线视频| 亚洲自拍三区| 亚洲一区尤物| 欧美日韩一二三区| 亚洲激情视频在线| 国产午夜精品久久久久久免费视| 亚洲乱码视频| 亚洲色诱最新| 欧美日韩一区精品| 妖精视频成人观看www| 一区二区三区日韩欧美精品| 蜜桃久久av一区| 亚洲第一久久影院| 亚洲日韩欧美视频| 欧美日韩成人综合天天影院| 亚洲国产精品黑人久久久| 亚洲精品无人区| 欧美日韩日本国产亚洲在线| 99www免费人成精品| 亚洲一区精品视频| 国产精品爽黄69| 久久gogo国模裸体人体| 久久人91精品久久久久久不卡| 影音先锋另类| 欧美精品在线观看91| 一本色道久久综合亚洲精品小说| 国产精品99久久久久久久vr| 国产精品久久久久久影院8一贰佰| 亚洲女优在线| 免费在线欧美视频| 日韩一级精品| 国产精品视频免费在线观看| 欧美在线国产精品| 欧美成人午夜激情| 一本大道久久a久久精二百| 国产精品久久久久久av福利软件| 欧美亚洲视频在线观看| 欧美v国产在线一区二区三区| 9l国产精品久久久久麻豆| 国产精品日本一区二区| 久久精品国产综合| 亚洲精品资源| 久久人人97超碰精品888| 一本色道久久88亚洲综合88| 国产女主播在线一区二区| 久久日韩精品| 一区二区三区福利| 蜜臀av一级做a爰片久久| 一道本一区二区| 国内久久婷婷综合| 欧美日韩另类一区| 久久久精品五月天| 中日韩高清电影网| 久久久一二三| 欧美午夜视频| 亚洲影院高清在线| 亚洲专区一区| 亚洲黄一区二区三区| 亚洲人成在线影院| 亚洲日本中文字幕免费在线不卡| 国产精品卡一卡二| 欧美成人a视频| 午夜日韩福利| 亚洲精一区二区三区| 久久一区中文字幕| 亚洲欧美电影在线观看| 亚洲人精品午夜在线观看| 国产视频一区免费看| 欧美日韩一区二区国产| 久久精品久久99精品久久| 一区二区国产日产| 亚洲第一在线视频| 久久久精品一区| 午夜精品国产更新| 亚洲午夜一区二区三区| 亚洲黄色影片| 136国产福利精品导航网址应用| 国产精品乱码久久久久久| 欧美精品在线免费| 欧美freesex交免费视频| 久久国产精品久久久久久电车| 亚洲午夜在线观看| 中日韩男男gay无套| 一级日韩一区在线观看| 亚洲精品国产精品国产自| 亚洲国产成人午夜在线一区 | 亚洲精品国精品久久99热一| 国产一区二区三区高清播放| 国产精品久久久久久久一区探花| 欧美日韩国产精品一卡| 欧美精品一区二| 欧美人交a欧美精品| 欧美成人自拍| 欧美精品久久99久久在免费线| 欧美成年视频| 欧美日韩精品在线| 欧美深夜影院| 国产精品婷婷| 国产丝袜一区二区三区| 韩国自拍一区| 亚洲国产精品久久| 亚洲精品在线免费| 宅男在线国产精品| 午夜精品一区二区三区四区| 欧美一区二区高清| 久久激情综合| 免费在线看成人av| 亚洲国产高潮在线观看| 亚洲精品在线免费| 亚洲午夜免费福利视频| 欧美一区二区精品在线| 久久色在线观看| 欧美国产精品v| 国产精品第2页| 国产综合精品| 亚洲国产精品va在看黑人| 99视频精品| 性色一区二区| 久久婷婷麻豆| 亚洲人成高清| 亚洲综合精品自拍| 久久影院亚洲| 欧美午夜精品久久久久久超碰| 国产精品一区二区欧美| 激情成人av在线| 一区二区日韩| 久久久久久国产精品mv| 亚洲激情在线激情| 亚洲欧美激情视频| 欧美91大片| 国产精品一区二区三区免费观看| 在线观看一区二区视频| 亚洲综合色在线| 免费在线一区二区| 亚洲天堂av高清| 免费成人av在线看| 国产精自产拍久久久久久蜜| 亚洲一区二区在线免费观看视频| 欧美 日韩 国产 一区| 国产精品二区在线| 亚洲国产日韩在线| 欧美一区二区三区在线视频| 欧美激情精品久久久六区热门| 亚洲天堂网在线观看| 麻豆国产精品777777在线 | 久久久免费精品视频| 亚洲精品乱码久久久久久日本蜜臀| 亚洲在线黄色| 欧美乱妇高清无乱码| 韩国精品一区二区三区| 亚洲一区二区日本| 欧美激情小视频| 欧美一区二区三区的| 欧美视频一区二区|